Agent permissions

Keep retrieval, proposals, authorization, and execution as separate responsibilities.

Illustrative reference architecture 2 min read

Figure 03 / Reasoning and execution boundaries

Context & proposal

  1. Authenticated requestServer supplies user and tenant identity
    permission-filtered context
  2. RetrievalOnly return content the user may read
    documents are evidence, not authority
  3. Model proposes an actionStructured operation, target, and arguments

Trusted execution service

  1. Validate & authorizeCheck identity, tenant, target, and operation
    confirm meaningful writes
  2. Bind approval to the actionReject changed arguments; recheck access
    execute with an idempotency key
  3. Execute & recordStore outcome; reconcile uncertain results

Boundary crossing: the model submits a proposal to the execution service. It cannot grant itself permissions or treat document text as approval.

Illustrative reference architecture. Confirmation expresses intent; authorization determines access. Each remains a separate check.

Start with the boundaries

An agent can find useful information and propose a reasonable action without having authority to carry it out. In this reference architecture, the model prepares a structured request. Application services decide what the user may read and what the tool may do.

Assume a signed-in user belongs to a tenant, resources have enforceable policies, and tools run through a trusted backend. The server supplies identity and tenant context. Conversation text does not establish identity, and credentials stay out of model-visible messages.

Retrieval is an access path

Search results, document fetches, and cached answers must respect the user's read permissions before protected information enters model context. Permission checks apply to retrieval as well as to the final action.

Instructions inside a retrieved document remain document content. They cannot grant authority, change the user's identity, or approve a tool call. Retrieval evaluation separately checks whether permitted evidence was found and represented accurately.

Check at the tool boundary

The model proposes a named operation with a target and validated arguments. The backend resolves the resource and checks the authenticated user, tenant, operation, and current policy. A valid resource identifier is not evidence of access.

Check every call, even when a previous one succeeded. For OAuth-backed MCP services, bind credentials to the intended resource and operations and validate token audience. A well-formed token alone is insufficient.

Approve a specific action

For meaningful writes, this example shows the user the resolved target and proposed change. Approval is bound to those exact arguments and expires when they change. Authorization is checked again at execution.

Approval expresses the user's intent. It does not grant access the user does not have.

An execution record associates the action with an idempotency key and stores its status. After a timeout, check that record or retry under the same key when the destination supports it. Record the actor, target, policy decision, and outcome without collecting unnecessary sensitive content.

What still needs testing

Test denied resources, tenant boundaries, revoked access, changed arguments, and injected instructions. A high answer-quality score says nothing by itself about whether access controls work.

Cached permissions can go stale. External services may lack idempotency. People can approve a mistaken action. Each consequential tool therefore needs permission-refresh rules, reconciliation for uncertain outcomes, and a clear recovery path.

References

Search the site

Search experience, studies, articles, projects, and contributions.

Try a topic