Identity, Permissions and Guardrails

Permission Is a Runtime Decision

An AI request is not authority to act. Separate the requesting user, the application credential and the logical agent; enforce access at each tool and resource boundary.

Three Identities in One Action

Shared credentials obscure who requested and executed an action. Bind each decision to the appropriate identities and record the effective authority.

Delegated Versus Application Access

Delegated access acts on behalf of a signed-in user and can preserve their resource permissions. Application access acts as the service itself, often across users, so constrain its resources and actions independently. Where the workflow permits, delegated access often offers a narrower least-privilege boundary; background jobs may need application access with explicit scope and oversight.

Reduce Standing Privilege

Prefer just-in-time credentials, short-lived tokens and scoped access. Keep secrets in a vault, rotate credentials and expire temporary elevation after the authorized task. Recheck scope at execution; a once-approved token must not become indefinite permission.

Authorization Models Outside the Model

These models can be combined. The policy engine and downstream system—not the language model—must make and enforce the authorization decision.

Layered Guardrails

Validate inputs, tool arguments and outputs against schemas and policy. Apply rate and step limits, destination allowlists and data-class routing before execution. Check the actual target and user context after tool selection; filter unsafe output before delivery. A prompt instruction is not a security boundary. Denials should stop the action rather than invite an alternate unguarded tool.

Human Approval With Specific Context

Require an appropriate approval for external sends, record changes, permission grants and other consequential operations. Show the exact proposed change, target and likely consequences to an authorized reviewer; capture the approver and decision before executing. Bind approval to that specific target and change, and recheck authorization at execution so a later edit cannot reuse stale approval. Group low-risk reviews sensibly and prioritize consequential ones to prevent approval fatigue, without hiding material changes.

Agentic Security Risks

Excessive agency can turn a narrow task into broad tool misuse. Identity abuse and privilege escalation can cross user or tenant boundaries; goal hijacking can redirect an agent through untrusted content. Contain these risks through narrowly scoped credentials, server-side policy, authenticated tool calls and traceable denials—not through prompt wording alone.

Red-Team the Access Boundary

Test unauthorized tools, prompt injection in retrieved content, malicious tool outputs, approval bypass, token misuse and privilege expansion. Include cross-tenant targets and alternate paths to the same operation. Verify denial at the downstream boundary, record evidence and rerun tests when permissions, tools or policies change.

Implementation and Deliverables

Inventory actors, resources and consequential actions; map delegated and application flows; implement policy checks and approval gates; test negative cases before rollout. Deliver an identity model, access matrix, approval matrix, guardrail architecture, abuse-case test suite and periodic review process.

Related: AI Security · AI Governance · MCP and API Integration · Controlled Tool Access

Frequently Asked Questions

Map an Action Boundary

Bring one proposed agent action and its target system. We can identify the identities, permission checks and approval point it needs.