RFC-0011: Access-Aware Coordination
Context injection, capability declaration, delegation primitives, and policy-as-code for intent-level access-aware coordination across agents and principals.
Abstract
This RFC defines access-aware coordination for the OpenIntent protocol. Rather than treating access control as a static permissions layer, it introduces context injection, capability declaration, delegation primitives, and policy-as-code so that agents can discover, request, and exercise fine-grained capabilities at runtime. Every grant, delegation, and policy evaluation is auditable and integrates with RFC-0003 Governance.
Context Injection
When an agent joins an intent, the coordination layer injects an access context describing the principal's identity, effective capabilities, active delegations, and applicable policies. This context travels with every request so that downstream services can make authorization decisions without additional round-trips.
Capability Declaration
- read — View intent metadata, state, events, attachments, and cost summaries
- write — All of read, plus: patch state, emit events, acquire leases, add attachments, record costs
- admin — All of write, plus: change status, modify ACL, configure retry policies, create children, request arbitration
- delegate — Grant a subset of own capabilities to another principal with scope and time constraints
Delegation Primitives
A principal holding sufficient capabilities may delegate a scoped subset to another agent. Delegations are time-bounded, revocable, and recorded as first-class events. Chained delegation is supported up to a configurable depth, preventing unbounded privilege propagation.
{
"intent_id": "uuid",
"delegator": "agent-coordinator",
"delegate": "agent-research",
"capabilities": ["read", "write"],
"scope": "state.research_*",
"max_depth": 1,
"expires_at": "ISO 8601",
"granted_at": "ISO 8601"
}
Policy-as-Code
Access policies are expressed as declarative rules evaluated at request time. Policies reference principal attributes, intent metadata, and environmental conditions. They compose with the capability model: a request succeeds only when at least one policy path grants the required capability and no deny rule fires.
Endpoints
- GET /v1/intents/{id}/acl — Get the intent's ACL and effective policies
- PUT /v1/intents/{id}/acl — Set the intent's ACL
- POST /v1/intents/{id}/acl/entries — Grant access
- DELETE /v1/intents/{id}/acl/entries/{entryId} — Revoke access
- POST /v1/intents/{id}/access-requests — Submit access request
- GET /v1/intents/{id}/access-requests — List access requests
- POST /v1/intents/{id}/access-requests/{requestId}/approve — Approve
- POST /v1/intents/{id}/access-requests/{requestId}/deny — Deny
Event Types
- access_granted — A principal was granted a capability
- access_revoked — A principal's capability was revoked
- access_expired — A time-limited grant expired
- access_requested — A principal requested access
- access_request_approved — An access request was approved
- access_request_denied — An access request was denied