Key findings

• Treat an agent as a first-class workload identity, not a shared employee account.

• Minimize agency as well as permissions: remove unnecessary tools and autonomy.

• Authorize every tool call in code against identity, user, action, resource, and context.

• Use temporary elevation and approval for exceptional high-impact actions.

• Test disablement, token revocation, credential rotation, and stale-access removal.

Start with the agent's blast radius

List every system the agent can access, every action it can call, every data set it can retrieve, and every downstream identity it can impersonate. Then model what happens if the agent is manipulated by prompt injection, receives a poisoned document, misinterprets a goal, loops, or is compromised. Risk is not limited to the model's response; it includes the cumulative reach of its tools and credentials.

OWASP's guidance identifies prompt injection, sensitive information disclosure, improper output handling, excessive agency, identity and privilege abuse, and tool misuse as central agent risks. Reduce the blast radius before improving prompts. An agent that can only read a designated support queue and draft into a staging table is safer than one that can search all mail and send messages, even if both have the same system instructions.

Give each agent a dedicated identity and owner

Use a managed service or workload identity for each production agent or materially different workflow. Do not reuse an employee's token, a global integration credential, or one shared service account across unrelated automations. Dedicated identities make authorization, audit, disablement, and lifecycle management possible. Record owner, purpose, environment, connected tools, approved scopes, creation date, review date, and expiry.

Manage the identity with the resource it serves. Disable it when the agent or environment is retired. Google Cloud's service-account guidance recommends single-purpose accounts and warns that shared accounts accumulate access and weaken attribution. Current Microsoft guidance similarly treats agent identity, narrow scope, auditability, and revocation as foundational controls.

Design an action and resource permission matrix

For each tool, specify allowed verbs and resources. Read customer cases does not imply export all customers. Update ticket status does not imply delete ticket. Query invoices does not imply initiate payment. Scope by tenant, mailbox, folder, project, table, row filter, field, record owner, region, amount, and time where the platform supports it. Deny by default.

Separate read, propose, approve, and execute. Give the model a read tool and a proposal tool; place execution behind a deterministic service that validates policy and, when required, human approval. Avoid generic execute SQL, run shell, send HTTP, or call any endpoint tools in production. If a flexible tool is unavoidable, sandbox it, restrict destinations and commands, validate inputs, and limit output size.

• Identity dimension: which agent and on behalf of which authenticated user?

• Action dimension: which exact verb is permitted?

• Resource dimension: which tenant, object, row, field, recipient, or destination?

• Context dimension: which amount, time, environment, approval, and risk condition?

Enforce authorization outside the model

The model may propose a tool call but must not be trusted to approve it. The execution layer should authenticate the agent, bind the requesting user where relevant, check action and resource policy, validate the argument schema, enforce business limits, and return only the minimum result. Treat tool output as untrusted because it can contain malicious instructions that attempt to influence the next step.

Use immutable policy where practical and keep policy changes outside the agent's permissions. Do not give an agent the ability to grant roles, change its allowlist, edit approval thresholds, access secrets, or disable logging. Validate outputs before passing them to databases, browsers, code interpreters, messaging systems, or other agents. Authorization failures should be explicit events, not text the model can reinterpret.

Prefer short-lived and just-in-time access

Use workload identity federation, managed identities, delegated tokens, or platform equivalents instead of long-lived static keys. Tokens should have narrow audience, scope, and lifetime. Store unavoidable secrets in a managed secret store, keep them out of prompts and logs, rotate them, and prevent the agent from reading unrelated credentials.

For exceptional actions, elevate access only after a policy condition or human approval and only for the required duration. Bind approval to the exact action, resource, parameters, and expiry so the agent cannot reuse a broad approval later. Limit transaction amount, action count, recursion, retries, and tool-chain depth. Temporary privilege reduces the period in which manipulation can cause damage.

Add approvals for consequential actions

Require review before payments, refunds above a threshold, external commitments, deletion, access changes, publication, account restriction, or disclosure of sensitive information. Show the reviewer the requested action, target, source evidence, agent identity, on-behalf-of user, policy result, and material parameters. Approval should authorize only that operation.

Use two-person control where the consequence warrants it. Keep a deterministic ceiling that no approval can exceed without a different process. Ensure reviewers can reject, edit, and escalate. If the queue is unavailable, fail safely or route to the existing manual process; do not silently downgrade to autonomous execution.

Audit, review, and revoke

Log identity, delegated user, action, resource, arguments after redaction, authorization decision, policy version, approval, result, error, and correlation ID. Correlate application traces with cloud and SaaS audit logs. Alert on denied calls, unusual resources, new tools, permission changes, high rates, repeated retries, privilege elevation, large exports, and activity outside expected hours.

Review effective permissions, not only assigned roles, because group membership, inherited access, shared connectors, and downstream delegation can expand reach. Remove unused permissions and tools. Test the kill switch, identity disablement, token invalidation, secret rotation, and connector revocation in the actual production path. A revocation plan that has never been exercised is an assumption.

Use a secure reference pattern

A practical pattern is: authenticated user requests a bounded task; orchestrator assigns a trace and agent identity; model proposes a structured tool call; policy gateway validates identity, action, resource, context, and approval; narrow tool executes with a short-lived credential; result is minimized and returned; output is validated; every step is logged. High-impact calls pause at the gateway.

This architecture accepts that models are probabilistic and external content can be hostile. It does not rely on the model remembering a security instruction. NIST zero-trust guidance rejects implicit trust based on location or ownership, and the same principle applies to agents: authenticate and authorize access to each protected resource based on explicit policy.

Sources and methodology

This article synthesizes the primary sources below as of the publication date. Forecasts and recommendations are directional scenarios, not guarantees; they should be tested against your workflow, data, risk tolerance, and current vendor documentation.

OWASP Foundation: OWASP AI Agent Security Cheat Sheet (accessed 2026-07-30)

OWASP Foundation: OWASP Top 10 for Agentic Applications (accessed 2026-07-30)

National Institute of Standards and Technology: Zero Trust Architecture, NIST SP 800-207 (accessed 2026-07-30)

Google Cloud: Best practices for using service accounts securely (accessed 2026-07-30)

Microsoft: Least privilege for AI agents (accessed 2026-07-30)

UK National Cyber Security Centre: Guidelines for secure AI system development (accessed 2026-07-30)