PRD-027 — Agentic Identity, Delegation & Credentialed Agency

1. Objetivo

O PRD-027 define a camada de identidade e autoridade delegada do Agentic Work.

Com os PRDs anteriores, já temos:

usuários;
tenants;
agentes especialistas;
capabilities;
policies;
integrações externas;
workflows;
decisões;
auditoria.

Agora precisamos responder de forma inequívoca:

Quem está agindo, em nome de quem, com qual autoridade e utilizando qual credencial?

O objetivo é impedir que o conceito de “agente” se transforme em uma identidade privilegiada capaz de fazer tudo.

A regra fundamental será:

User Identity
      ↓
Delegation
      ↓
Agent Identity
      ↓
Capability
      ↓
Policy
      ↓
Credential
      ↓
External Operation

2. Princípio Fundamental

O Agentic Work deverá distinguir quatro conceitos:

Conceito	Significado
Identity	Quem é a entidade
Authority	O que ela pode fazer
Delegation	Quem concedeu a autoridade
Credential	Como a operação é autenticada no sistema alvo

Portanto:

Identity ≠ Permission
Permission ≠ Credential
Credential ≠ Delegation

3. Exemplo

Um usuário solicita:

“Atualize o treinamento desse funcionário no LMS.”

Não basta saber que:

training-agent

está executando.

Precisamos preservar:

Haroldo
   ↓
solicitou operação
   ↓
Supervisor Agent
   ↓
Training Agent
   ↓
training.external.update
   ↓
Policy
   ↓
LMS Credential

A auditoria deverá conseguir reconstruir essa cadeia.

4. Arquitetura

                         USER
                           │
                           ▼
                    Authentication
                           │
                           ▼
                     User Session
                           │
                           ▼
                 Agent Delegation Layer
                           │
                           ▼
                    Agent Identity
                           │
                           ▼
                  Capability Registry
                           │
                           ▼
                     Policy Engine
                           │
                           ▼
                 Credential Resolver
                           │
                           ▼
              External Integration Gateway
                           │
                           ▼
                   External System

5. Identity Model

O sistema deverá possuir identidades distintas:

HUMAN
AGENT
SERVICE
SYSTEM
EXTERNAL

Exemplo:

type PrincipalType =
  | "HUMAN"
  | "AGENT"
  | "SERVICE"
  | "SYSTEM"
  | "EXTERNAL";

6. Principal

Todos os atores deverão ser representados por um Principal.

interface Principal {
  principalId: string;

  type: PrincipalType;

  tenantId?: string;

  status: "ACTIVE" | "SUSPENDED" | "REVOKED";

  createdAt: string;
}

7. Human Principal

Representa o usuário autenticado.

interface HumanPrincipal extends Principal {
  type: "HUMAN";

  userId: string;

  roles: string[];

  permissions: string[];
}

O userId deverá vir do sistema de identidade/autenticação confiável.

Nunca deverá ser confiado a um campo enviado pelo LLM.

8. Agent Principal

interface AgentPrincipal extends Principal {
  type: "AGENT";

  agentId: string;

  agentVersion: string;

  parentAgentId?: string;

  delegationId?: string;
}

9. Agent Identity ≠ User Identity

O agente deverá possuir identidade própria.

Porém:

Agent = executor
User = authority source

quando a ação for iniciada pelo usuário.

Isso permite distinguir:

“O agente executou”

de:

“O usuário autorizou.”

10. Delegation

Delegation representa a autorização para um agente atuar dentro de determinado escopo.

interface AgentDelegation {
  delegationId: string;

  delegatorPrincipalId: string;

  delegatePrincipalId: string;

  tenantId: string;

  scopes: string[];

  capabilities: string[];

  resources?: ResourceScope[];

  validFrom: string;

  expiresAt: string;

  status:
    | "ACTIVE"
    | "EXPIRED"
    | "REVOKED";
}

11. Delegation Chain

Em um sistema multi-agent:

User
 ↓
Supervisor
 ↓
Training Agent

deverá existir:

delegationChain:
[
  user → supervisor,
  supervisor → training-agent
]

Isso permitirá verificar a origem da autoridade.

12. Authority Cannot Expand

A regra mais importante:

Delegação só pode manter ou reduzir autoridade; nunca aumentá-la.

Se:

User:
training.read

o Supervisor não poderá delegar:

training.write

ao Training Agent.

Formalmente:

AgentAuthority ⊆ DelegatorAuthority

considerando também as políticas sistêmicas.

13. Capability Scope

Delegação poderá ser limitada por capability.

scopes:
  - training.getStatus
  - training.getCertificate

Isso é preferível a:

scope: training.*

quando apenas duas operações são necessárias.

14. Resource Scope

A delegação também poderá ser limitada a recursos.

interface ResourceScope {
  resourceType: string;

  resourceIds?: string[];

  filters?: Record<string, unknown>;
}

Exemplo:

Training Agent
→ pode consultar apenas os funcionários vinculados à Work Permit WP-10231

15. Time-Bound Delegation

Delegações deverão ter validade.

validFrom
expiresAt

Isso impede permissões eternas.

Exemplo:

Delegation:
15:00 → 15:10

Depois disso:

EXPIRED

16. Explicit Revocation

Uma delegação deverá poder ser revogada imediatamente.

ACTIVE
   ↓
REVOKED

A revogação deverá ser considerada pelo Policy Engine antes de cada operação relevante.

17. Delegation Token

Quando apropriado, a delegação poderá ser representada por um token de curta duração.

O token deverá conter somente informações necessárias, como:

subject
issuer
audience
tenant
scopes
delegationId
issuedAt
expiresAt

Nunca deverá conter segredos desnecessários.

18. Short-Lived Tokens

Tokens de agente deverão possuir vida curta.

Exemplo conceitual:

User authentication
      ↓
Delegation token
      ↓
Agent execution
      ↓
expires

Não deverá existir um token universal permanente para o Agentic Work.

19. Audience Restriction

Um token destinado ao:

Training Gateway

não deverá ser aceito pelo:

Payroll Gateway

Portanto deverá existir um audience explícito.

aud = training-gateway

20. Scope Restriction

O token também deverá possuir scopes mínimos.

training.read

não deverá permitir:

training.write

21. Credential Types

O Credential Manager deverá suportar abstrações para:

API Key
OAuth Access Token
OAuth Refresh Token
JWT
mTLS Certificate
Service Account
Basic Authentication
Signed Request

O Gateway decidirá qual mecanismo utilizar.

22. Credential Vault

Credenciais deverão ser armazenadas em um Credential/Secret Store apropriado.

O Agent Runtime deverá receber apenas:

credential reference

e nunca:

raw secret

23. Credential Reference

interface CredentialReference {
  credentialId: string;

  integrationId: string;

  tenantId: string;

  purpose: string;

  status: "ACTIVE" | "EXPIRED" | "REVOKED";
}

24. Credential Resolver

Fluxo:

Capability
 ↓
Integration
 ↓
Tenant
 ↓
Credential Reference
 ↓
Credential Resolver
 ↓
Secret Store
 ↓
Authenticated Request

O secret deverá permanecer dentro da infraestrutura de execução.

25. Credential Isolation

Uma credencial de:

Tenant A / LMS

jamais poderá ser usada por:

Tenant B / LMS

mesmo que ambos usem o mesmo adapter.

26. Credential Purpose Binding

Uma credencial poderá ser limitada a uma finalidade.

Exemplo:

credential:
lms-read-only

não deverá ser utilizada por:

training.external.update

27. Read vs Write Credentials

Quando o fornecedor permitir, deverão existir credenciais separadas:

LMS_READ
LMS_WRITE

Isso reduz o blast radius.

28. Credential Rotation

O sistema deverá suportar:

ACTIVE credential
       ↓
NEW credential
       ↓
VALIDATION
       ↓
CUTOVER
       ↓
OLD credential revoked

A rotação não deverá exigir alteração do Agent Runtime.

29. OAuth

Para integrações OAuth, deverá existir:

Authorization Server
       ↓
Access Token
       ↓
External Gateway

Tokens expirados deverão ser renovados de maneira controlada.

O LLM nunca participa do processo de refresh.

30. Refresh Token

Refresh tokens deverão permanecer exclusivamente no Credential/Identity Layer.

Nunca:

LLM → refresh_token

31. User-Delegated OAuth

Quando o sistema externo suportar delegação por usuário:

User
 ↓
OAuth Consent
 ↓
External Account
 ↓
Delegated Credential

a associação deverá ser explicitamente armazenada.

32. Consent

Algumas integrações poderão exigir consentimento do usuário.

Exemplo:

“Permitir que o Agentic Work consulte seu calendário corporativo?”

O consentimento deverá possuir:

purpose
scopes
integration
user
tenant
timestamp
expiration

33. Reauthentication

Operações de alto risco poderão exigir autenticação novamente.

Exemplo:

User authenticated
       ↓
Agent operation
       ↓
HIGH RISK
       ↓
Step-up authentication
       ↓
Continue

Isso é diferente de uma simples confirmação textual.

34. Confirmation vs Reauthentication

Confirmation

“Deseja realmente liberar esta permissão?”

Reauthentication

“Confirme sua identidade novamente para executar esta operação.”

São mecanismos distintos.

35. Service Identity

Alguns workflows automáticos não terão um usuário ativo.

Exemplo:

TrainingExpirationScanner

Nesse caso:

SYSTEM
 ↓
Service Principal
 ↓
Workflow
 ↓
Capability

A operação deverá possuir uma policy explícita.

36. System-Triggered Operations

Um evento como:

TrainingExpired

poderá iniciar um workflow.

Mas o sistema não deverá assumir automaticamente que:

SYSTEM

tem permissão para qualquer operação.

37. Machine-to-Machine Authorization

Serviços internos também deverão utilizar identidade.

Workflow Runtime
 ↓
Service Identity
 ↓
Capability
 ↓
Policy

Não deverá existir uma “shared secret” global utilizada por todos os Workers.

38. Internal Service Identity

interface ServicePrincipal extends Principal {
  type: "SERVICE";

  serviceId: string;

  serviceVersion: string;

  allowedAudiences: string[];
}

39. mTLS

Quando necessário, integrações de alto nível de segurança poderão utilizar:

mTLS

com certificado associado ao integration identity.

O certificado deverá ser gerenciado pelo Credential Layer.

40. External Identity Mapping

Um funcionário poderá possuir IDs diferentes:

SST:
EMP-104

HR:
A-8732

LMS:
worker-99281

O Identity Mapping Layer deverá relacioná-los.

interface ExternalIdentityMapping {
  internalEntityType: string;

  internalEntityId: string;

  integrationId: string;

  externalEntityType: string;

  externalEntityId: string;

  verified: boolean;
}

41. Identity Resolution

Exemplo:

Work Permit
WP-10231
 ↓
Employee
EMP-104
 ↓
LMS identity
worker-99281

A resolução deverá ser determinística sempre que possível.

42. Ambiguous Identity

Se houver:

EMP-104
→ LMS worker-1
→ LMS worker-2

o agente não deverá escolher arbitrariamente.

Resultado:

IDENTITY_AMBIGUOUS

e deverá solicitar resolução.

43. Tenant Identity Boundary

O mapping deverá conter tenantId.

Isso impede:

Tenant A:
EMP-104

Tenant B:
EMP-104

de serem tratados como a mesma identidade.

44. Delegation Context

Todo request deverá transportar um contexto equivalente a:

interface AgencyContext {
  actor: Principal;

  delegator?: Principal;

  delegationChain: string[];

  tenantId: string;

  scopes: string[];

  capabilities: string[];

  sessionId?: string;

  conversationId?: string;

  executionId: string;
}

45. Policy Evaluation

O Policy Engine do PRD-008 deverá avaliar:

User
+
Agent
+
Delegation
+
Capability
+
Resource
+
Tenant
+
Context

Não apenas:

Agent → Capability

46. Policy Example

User:
training.write

Agent:
training-agent

Delegation:
training.write

Capability:
training.external.update

Resource:
EMP-104

Tenant:
TENANT-A

Policy:

ALLOW

somente se todas as condições forem satisfeitas.

47. Delegation Violation

Exemplo:

User
→ training.read

Agent
→ training.write

Resultado:

DENY
reason:
DELEGATION_SCOPE_EXCEEDED

48. Delegation Depth

Deverá existir limite de delegação.

User
 ↓ 1
Supervisor
 ↓ 2
Training Agent
 ↓ 3
External Agent

Uma profundidade excessiva deverá ser bloqueada.

49. No Recursive Delegation

Um agente não deverá poder delegar autoridade para si mesmo.

Nem deverá criar uma cadeia circular:

A
 ↓
B
 ↓
A

50. Delegation by Capability

A delegação deverá ser preferencialmente orientada a capabilities, e não a APIs.

Correto:

training.getStatus

Não:

POST /api/v1/lms/worker/status

51. Delegation by Resource

Quando possível:

workPermit.updateValidity

poderá ser restringida a:

WP-10231

em vez de todas as permissões do tenant.

52. Bulk Operations

Delegação deverá tratar operações em lote separadamente.

Exemplo:

training.update

não implica:

training.bulkUpdate

Batch deverá exigir capability e policy próprias.

53. Two-Person Rule

Operações críticas poderão exigir duas identidades humanas.

Exemplo:

Agent
 ↓
Prepare release
 ↓
Human A approval
 ↓
Human B approval
 ↓
Execute

O agente não poderá representar os dois aprovadores.

54. Segregation of Duties

O sistema deverá impedir situações como:

User A creates
       ↓
same user
       ↓
approves

quando a policy exigir separação.

Isso deverá integrar-se ao PRD-008.

55. Agent Impersonation

Impersonation deverá ser proibida por padrão.

Não deverá existir:

Agent → "become User B"

sem mecanismo administrativo explícito.

Mesmo quando permitido, deverá gerar auditoria de alto nível.

56. Actor Chain

Toda operação deverá possuir:

initiatedBy
delegatedTo
executedBy
authenticatedAs
authorizedBy

Exemplo:

{
  "initiatedBy": "user:EMP-10",
  "delegatedTo": "agent:supervisor",
  "executedBy": "agent:training",
  "authorizedBy": "policy:training-write-v4"
}

57. Audit Integration

O PRD-013 deverá receber:

principal
delegator
delegationId
agentId
credentialId
capabilityId
policyVersion

mas nunca o segredo da credencial.

58. Credential Audit

Deverá ser possível saber:

Qual credencial foi utilizada?

Mas não:

Qual era o valor do segredo?

Exemplo:

credentialId:
cred_lms_tenant_a_01

59. Secret Redaction

Os seguintes valores deverão ser automaticamente redigidos:

Authorization
API-Key
Cookie
Refresh Token
Client Secret
Private Key
Password
Webhook Secret

em logs e traces.

60. Emergency Revocation

Deverá existir capacidade de:

revoke user
revoke agent
revoke delegation
revoke credential
disable integration
disable capability

independentemente.

61. Emergency Kill Chain

Exemplo:

Credential compromised
 ↓
Revoke Credential
 ↓
Disable Integration
 ↓
Invalidate Delegations
 ↓
Stop Workflows
 ↓
Alert Security

Isso deverá integrar-se ao PRD-024.

62. Agent Suspension

Se um agente apresentar comportamento anômalo:

training-agent
STATUS = SUSPENDED

As tarefas novas deverão ser bloqueadas.

Tarefas existentes poderão:

pause
cancel
migrate

conforme policy.

63. Credential Health

O Credential Manager deverá monitorar:

expiration
authentication failures
rotation age
usage
provider errors
revocation status

64. Credential Least Privilege

Sempre que possível:

read-only credential

deverá ser usada para operações de leitura.

Uma credencial de escrita somente deverá ser disponibilizada para capabilities que realmente precisam dela.

65. Credential Just-in-Time

Para operações críticas, poderá ser adotado:

Capability Request
 ↓
Policy
 ↓
Temporary Credential
 ↓
Operation
 ↓
Credential Destroy/Expire

Isso reduz exposição de credenciais.

66. External Gateway Integration

O PRD-025 deverá receber:

AgencyContext
CredentialReference
DelegationId

e nunca simplesmente:

userId

como parâmetro livre.

67. Workflow Integration

Workflows longos deverão preservar a autoridade original.

Se um workflow durar três dias:

Day 1:
User → workflow

Day 3:
workflow → capability

não deverá automaticamente assumir que a autorização original ainda é válida.

Deverá verificar:

delegation expiration
user status
tenant status
policy version
capability status

68. Long-Running Delegation

Para workflows longos, deverá existir uma distinção entre:

User Authorization

Workflow Service Authority

Isso evita manter um token de usuário válido durante toda a vida do workflow.

69. Reauthorization

Antes de uma etapa crítica:

Workflow
 ↓
Policy
 ↓
Need reauthorization?
 ↓
YES
 ↓
Human approval/authentication

70. Event Fabric

Eventos deverão carregar o ator original.

Exemplo:

{
  "eventType": "WorkPermitReleased",
  "actor": {
    "type": "AGENT",
    "agentId": "work-permit-agent"
  },
  "initiatedBy": {
    "type": "HUMAN",
    "userId": "USR-104"
  }
}

Isso é essencial para auditoria e compliance.

71. External Webhook Identity

Eventos externos deverão possuir identidade do fornecedor:

source:
external-lms

externalPrincipal:
lms-system

tenantBinding:
TENANT-A

O sistema não deverá assumir que qualquer webhook pertence a um tenant.

72. Webhook Authentication

O Gateway deverá validar:

signature
issuer
audience
timestamp
nonce
tenant binding

antes de criar o evento interno.

73. Agent Credential Isolation

Cada agente deverá possuir acesso somente às credenciais necessárias.

Exemplo:

Training Agent
 ├── LMS read
 └── LMS write

Risk Agent
 └── nenhuma credencial externa

O Risk Agent não deverá receber a credencial do LMS simplesmente porque outro agente a possui.

74. Cross-Agent Credential Sharing

É proibido:

Agent A
 ↓
Credential
 ↓
Agent B

O correto é:

Agent B
 ↓
Capability
 ↓
Credential Resolver

O próprio Gateway resolve a credencial.

75. Agent-to-Agent Authentication

Quando agentes forem executados como serviços independentes:

Supervisor
 ↓
authenticated service request
 ↓
Training Agent

O receptor deverá validar:

sourceAgent
tenant
delegation
audience
task scope
expiration

76. Agent Contract Security

Além do schema:

inputSchema
outputSchema

o contrato deverá declarar:

requiredScopes
allowedCallers
maxDepth
dataClassification

77. Example Agent Contract

agentId: training-agent

allowedCallers:
  - work-permit-supervisor

requiredScopes:
  - training.read

dataClassification:
  input:
    - INTERNAL
  output:
    - INTERNAL

78. Agent Discovery Security

O Agent Registry não deverá revelar capabilities sensíveis para qualquer agente.

A descoberta deverá ser contextual:

caller
+
tenant
+
task
+
authorization

79. Multi-Tenant Agent Registry

Agentes globais poderão existir:

training-agent

mas sua disponibilidade poderá variar:

Tenant A → ACTIVE
Tenant B → DISABLED
Tenant C → CUSTOM VERSION

80. Tenant-Specific Delegation

Cada tenant poderá possuir policies específicas:

Tenant A:
training.write → confirmation

Tenant B:
training.write → approval

desde que nunca reduzam as proteções globais obrigatórias.

81. Global Security Boundary

A hierarquia será:

Global Security
       ↓
Tenant Policy
       ↓
User Permissions
       ↓
Agent Delegation
       ↓
Capability Policy
       ↓
Resource Policy

Uma camada inferior nunca poderá relaxar uma restrição global obrigatória.

82. Authorization Cache

Para performance, decisões poderão ser cacheadas.

Mas o cache deverá incluir:

user
agent
tenant
delegation
capability
resource
policyVersion
expiration

Uma mudança crítica deverá invalidar o cache.

83. Performance

O Identity/Delegation Layer deverá ser extremamente rápido.

Meta:

P50 < 5ms
P95 < 20ms

para decisões locais/cacheadas.

Operações externas não entram nesse orçamento.

84. Fail Closed

Em operações críticas:

Identity unavailable

deverá resultar em:

DENY

e não:

ALLOW

85. Security Event Detection

O sistema deverá detectar:

unusual agent activity
credential misuse
cross-tenant attempts
scope escalation
delegation loops
rapid credential switching
abnormal bulk operations

Esses eventos alimentarão o PRD-024.

86. Example — Secure External Operation

Usuário:

“Atualize o treinamento de João.”

Fluxo:

User Authentication
        ↓
Intent
        ↓
Supervisor
        ↓
Training Agent
        ↓
Delegation Validation
        ↓
Capability Selection
        ↓
Policy
        ↓
Credential Resolver
        ↓
External Gateway
        ↓
LMS
        ↓
Verification
        ↓
Audit

Em nenhum momento o LLM recebe:

API Key
OAuth Token
Password

87. Example — Unauthorized Delegation

Usuário possui:

training.read

Supervisor tenta delegar:

training.write

resultado:

DELEGATION_SCOPE_EXCEEDED

A operação nem deverá chegar ao External Gateway.

88. Example — Expired Delegation

Delegation:
expiresAt = 14:00

Operation:
14:03

Resultado:

DENY
DELEGATION_EXPIRED

Mesmo que o token de infraestrutura ainda esteja tecnicamente válido.

89. Example — Revoked Credential

Capability
 ↓
Credential Resolver
 ↓
credential = REVOKED

Resultado:

EXTERNAL_OPERATION_BLOCKED

O sistema não deverá tentar usar uma credencial antiga armazenada em cache.

90. Integration com todos os PRDs

O PRD-027 passa a funcionar como camada transversal:

PRD-003  Knowledge
PRD-004  Capabilities
PRD-005  Intent
PRD-006  Planner
PRD-007  Tool Runtime
PRD-008  Policy
PRD-009  Knowledge Binding
PRD-010  Conversation
PRD-011  UI
PRD-012  Learning
PRD-013  Audit
PRD-014  Testing
PRD-015  Observability
PRD-016  Release
PRD-017  Multi-Tenant
PRD-019  Workflow
PRD-020  Events
PRD-021  Proactive
PRD-022  Human Attention
PRD-023  Decision
PRD-024  Exception
PRD-025  External Gateway
PRD-026  Multi-Agent
       │
       ▼
PRD-027 Identity & Agency

91. Primeiro Vertical Slice

O primeiro vertical slice deverá implementar:

User

Human Principal

Agents

work-permit-supervisor
training-agent

Delegation

supervisor
→ training-agent

Capability

training.external.getStatus

External Credential

tenant-specific LMS read credential

92. Primeiro Teste

Usuário:

“Verifique se o treinamento de João está válido.”

Fluxo:

Human
 ↓
Supervisor
 ↓
Delegation
 ↓
Training Agent
 ↓
training.external.getStatus
 ↓
Policy
 ↓
Credential Resolver
 ↓
LMS
 ↓
Verification

Auditoria:

initiatedBy = HUMAN
delegatedTo = supervisor
executedBy = training-agent
capability = training.external.getStatus
credential = credential-reference
tenant = current-tenant

93. Segundo Teste

Usuário:

“Atualize o treinamento de João.”

Se a delegação permitir somente leitura:

DENY

sem qualquer chamada ao LMS.

94. Terceiro Teste

Credencial do tenant A é deliberadamente utilizada em contexto do tenant B.

Resultado obrigatório:

DENY
TENANT_CREDENTIAL_MISMATCH

95. Quarto Teste

Delegação expirada.

Resultado:

DENY
DELEGATION_EXPIRED

96. Quinto Teste

Training Agent tenta chamar diretamente:

https://qualquer-endpoint

Resultado:

DENY
UNREGISTERED_EXTERNAL_DESTINATION

97. Sexto Teste

Training Agent tenta solicitar uma capability fora de seu escopo:

workPermit.approve

Resultado:

DENY
CAPABILITY_NOT_DELEGATED

98. Critérios de Aceitação

Evidência parcial de implementação — 2026-09-04

Delegações persistidas e em memória são verificadas contra tenant, delegatário, audience, capability, recurso, período de validade e revogação; a validação de subset impede expansão de privilégios e auto-delegação. A referência de credencial é opaca, tenant-bound e purpose-bound, enquanto o executor externo resolve material de credencial fora do resultado do agente. Envelopes entre agentes restringem receiver/audience e rejeitam autoendereçamento; o gateway registra agência, política e delegação em audit.

Em 2026-09-05, os contratos de delegação, integração e comunicação passaram com 19 testes em 5 arquivos. O canário remoto comprovou cadeia de sete mensagens supervisionadas, ACKNOWLEDGED, causação, cancelamento, replay idempotente, rejeição de ordenação e payload sensível, hashes de corpo/contexto e ausência de autoridade; o cleanup confirmou remainingRows:0. O slice LMS autenticado também está comprovado pelo binding privado de renovação/confirmação. OAuth/OIDC, mTLS, rotação de credencial, cache de autorização e JIT credentials permanecem abertos para prova dedicada.

Em 2026-09-06, a regressão atual de autenticação, delegações e comunicação entre agentes passou com 17 testes. O typecheck do Agent passou novamente, e o health público do Worker confirmou runtime e bindings. A classificação PROVEN_CLOUDFLARE permanece apoiada no canário remoto já registrado; OAuth/OIDC, mTLS, rotação de credencial, cache de autorização e JIT credentials continuam fora do recorte comprovado.

99. Resultado Arquitetural

Com o PRD-027, finalmente teremos uma distinção formal entre:

              WHO?
                │
             Identity
                │
              WHY?
                │
           Delegation
                │
              WHAT?
                │
           Capability
                │
            ALLOWED?
                │
             Policy
                │
           HOW AUTH?
                │
           Credential
                │
           WHERE?
                │
        External Gateway

Isso fecha uma das lacunas mais importantes da arquitetura.

O Agentic Work agora pode ter agentes, workflows e integrações externas, mas nenhum deles recebe autoridade implícita.

PRD-028 — Agentic Knowledge Operations & Continuous Knowledge Fabric

O próximo PRD deverá atacar outro ponto fundamental: o conhecimento do agente não pode ser estático.

A arquitetura já possui:

TypeDoc
Docusaurus
Markdown
Obsidian
HAG
Keyword Index
BM25
Wikilinks
Vectorize
Semantic IDs

Mas agora teremos também:

Business Events
External Systems
Workflows
Decisions
Operational Learning
Documents
User Corrections

O PRD-028 deverá definir uma Knowledge Fabric contínua, capaz de transformar esses sinais em conhecimento estruturado, versionado, temporal, proveniente de fontes confiáveis e continuamente sincronizado com o HAG existente.

O objetivo será fazer com que o Agentic Work consiga responder não apenas:

“O que a documentação diz?”

mas também:

“Qual é o estado atual?”

“O que mudou?”

“Qual fonte é mais confiável?”

“Quando essa informação deixou de ser válida?”

“Qual decisão ou evento produziu esse conhecimento?”

A arquitetura prevista será:

Documentation ─────┐
Business APIs ─────┤
External Systems ──┤
Events ────────────┤
Workflows ─────────┤
Decisions ─────────┤
Operational Data ──┤
User Feedback ─────┘
          │
          ▼
   Knowledge Ingestion
          │
          ▼
   Validation & Provenance
          │
          ▼
   Temporal Knowledge
          │
          ▼
      HAG / Graph
          │
     ┌────┴────┐
     ▼         ▼
 BM25/Index  Vectorize
     │         │
     └────┬────┘
          ▼
   Agent Knowledge Layer

E, principalmente, esse PRD deverá definir a separação entre conhecimento estático, conhecimento operacional, fatos temporais, eventos, documentos, inferências e conhecimento aprendido, evitando que o sistema transforme automaticamente uma inferência do LLM em “verdade” permanente.

1. Objetivo​

2. Princípio Fundamental

3. Exemplo

4. Arquitetura

5. Identity Model

6. Principal

7. Human Principal

8. Agent Principal

9. Agent Identity ≠ User Identity

10. Delegation

11. Delegation Chain

12. Authority Cannot Expand

13. Capability Scope

14. Resource Scope

15. Time-Bound Delegation

16. Explicit Revocation

17. Delegation Token

18. Short-Lived Tokens

19. Audience Restriction

20. Scope Restriction

21. Credential Types

22. Credential Vault

23. Credential Reference

24. Credential Resolver

25. Credential Isolation

26. Credential Purpose Binding

27. Read vs Write Credentials

28. Credential Rotation

29. OAuth

30. Refresh Token

31. User-Delegated OAuth

32. Consent

33. Reauthentication

34. Confirmation vs Reauthentication

Confirmation​

Reauthentication​

35. Service Identity

36. System-Triggered Operations

37. Machine-to-Machine Authorization

38. Internal Service Identity

39. mTLS

40. External Identity Mapping

41. Identity Resolution

42. Ambiguous Identity

43. Tenant Identity Boundary

44. Delegation Context

45. Policy Evaluation

46. Policy Example

47. Delegation Violation

48. Delegation Depth

49. No Recursive Delegation

50. Delegation by Capability

51. Delegation by Resource

52. Bulk Operations

53. Two-Person Rule

54. Segregation of Duties

55. Agent Impersonation

56. Actor Chain

57. Audit Integration

58. Credential Audit

59. Secret Redaction

60. Emergency Revocation

61. Emergency Kill Chain

62. Agent Suspension

63. Credential Health

64. Credential Least Privilege

65. Credential Just-in-Time

66. External Gateway Integration

67. Workflow Integration

68. Long-Running Delegation

69. Reauthorization

70. Event Fabric

71. External Webhook Identity

72. Webhook Authentication

73. Agent Credential Isolation

74. Cross-Agent Credential Sharing

75. Agent-to-Agent Authentication

76. Agent Contract Security

77. Example Agent Contract

78. Agent Discovery Security

1. Objetivo

Confirmation

Reauthentication

User

Agents

Delegation

Capability

External Credential

Evidência parcial de implementação — 2026-09-04