AI agents often gain capabilities one integration at a time: read a calendar, search files, send email, create tickets, update a CRM. Over time, the collection becomes difficult to reason about. A tool permission manifest gives each deployed agent a machine-readable declaration of which tools it may call, which operations are allowed and which actions require additional approval.

Declare tools and operations separately

Access to an email service does not imply permission to send, delete and forward. The manifest should list operations at the granularity the product can enforce: read messages, search threads, create draft, send message or modify labels.

This makes overbroad integration visible early. A summarization agent may need read access but no sending capability, while a campaign agent may need drafts but still require human confirmation before external delivery.

Bind permissions to resources

Many tools support narrower resource scope: one folder, one calendar, one project or one tenant. The manifest should capture those limits rather than stopping at API-level access.

Resource constraints are particularly important in multi-tenant systems. They reduce the consequences of prompt injection and make accidental cross-project access easier to prevent.

Represent approval requirements explicitly

Some operations can run automatically up to a threshold and require approval above it. The manifest can encode these policies so the runtime does not rely on the model to remember a natural-language safety rule.

Examples include external email, payments, public publishing and destructive actions. Approval policy belongs beside the tool permission because authority depends on both what the agent can do and under what conditions it may do it.

Version the manifest with the agent

Adding a new connector or changing an allowed scope is a production change. Store a manifest version with the prompt, model and workflow configuration so every run can be linked to the permissions active at the time.

This improves incident review. If an agent unexpectedly modified a resource, operators can verify whether the action violated the manifest or whether the manifest itself was too broad.

Compare declared and observed capability use

Runtime telemetry can report which permissions are actually exercised. Capabilities that remain unused for weeks may be candidates for removal, while frequent approval escalations may show that the manifest is too restrictive for the intended workflow.

This creates a feedback loop between security and product operations instead of treating permission design as a one-time setup during integration.

Fail closed when the manifest is unclear

If a tool call cannot be matched to an allowed operation, the gateway should block it rather than asking the model to interpret whether the action is “close enough.” Deterministic enforcement belongs outside the language model.

Our article on ephemeral credentials for AI agents adds the time dimension. A manifest states what authority is allowed; short-lived credentials ensure that authority also expires automatically.

Permission manifests make agent capability legible. They help developers, operators and customers answer the same practical question before execution begins: what can this agent actually do, to which resources, and when does a human still need to approve the action?

A permission manifest is most useful when it becomes part of deployment review. Product teams can compare the manifest with actual tool traces and ask whether the agent used capabilities that were never declared, repeatedly requested unnecessary scope or depended on one unusually privileged action. This turns least privilege into something measurable. The manifest can also be shown in a simplified human view during onboarding, so administrators understand what the agent may read, create, send or delete before connecting an account. The technical and user-facing views should derive from the same source of truth rather than drifting into separate documentation.

A permission manifest is most useful when it becomes part of deployment review. Product teams can compare the manifest with actual tool traces and ask whether the agent used capabilities that were never declared, repeatedly requested unnecessary scope or depended on one unusually privileged action. This turns least privilege into something measurable. The manifest can also be shown in a simplified human view during onboarding, so administrators understand what the agent may read, create, send or delete before connecting an account. The technical and user-facing views should derive from the same source of truth rather than drifting into separate documentation.

A permission manifest is most useful when it becomes part of deployment review. Product teams can compare the manifest with actual tool traces and ask whether the agent used capabilities that were never declared, repeatedly requested unnecessary scope or depended on one unusually privileged action. This turns least privilege into something measurable. The manifest can also be shown in a simplified human view during onboarding, so administrators understand what the agent may read, create, send or delete before connecting an account. The technical and user-facing views should derive from the same source of truth rather than drifting into separate documentation.