Enterprise AI

Why AI Agents Need Zero-Trust Architecture

AI agents that call tools act through real identities and permissions. Apply zero-trust architecture with least privilege, delegated authorization, isolated credentials, audit trails and human approval.

A chatbot can return an incorrect answer. An agent connected to business systems can also open a ticket, retrieve a protected record, change a deployment or submit a transaction. The model does not have authority by itself; the application, agent runtime and connected tools provide that authority. But once a system lets model-directed workflows invoke those tools, its security design must account for the actions the system can perform.

That is why AI agents need zero-trust architecture. Every request to a resource should be evaluated using identity, authorization and relevant context. The system should not trust a request simply because it came from an internal network, an approved agent framework or a prompt that appears well intentioned. The agent’s actions need the same rigor as any other service identity—with additional controls for untrusted model inputs and delegated decisions.

NIST’s Zero Trust Architecture guidance defines the core premise: network location or asset ownership does not grant implicit trust, and access decisions should follow least-privilege principles. For agents, apply that premise to each tool call, data access and downstream operation.

Start by identifying whose authority is being used

An AI workflow may involve at least three different identities: the human or service that requested the work, the agent application that coordinates it, and the identity a tool uses to reach a downstream system. These identities must not be collapsed into one broad credential.

For user-specific work, preserve the user’s authorization when the downstream service supports delegated access. For background tasks or shared workflows, use a dedicated workload identity with permissions tailored to that function. The system should make the acting identity visible and should not use a highly privileged service account simply because it is easier to configure.

A key design question is: if the model is manipulated or makes a poor decision, which resources can the actual runtime identity reach, and what operations can it perform? The answer should be a small, documented set—not every resource available to the application team.

Apply zero-trust controls at each boundary

Authorize each agent action at the boundary that can enforce it
  1. RequestIdentify the user, task and target resource.
  2. AuthorizeCheck the user or workload identity and permitted scope.
  3. PrepareUse a narrow tool to propose a specific operation.
  4. ApprovePause for an authorized person when impact requires review.
  5. ExecuteRe-check scope and apply through a limited deployment identity.
  6. AuditRecord decision, approver, target and outcome without exposing secrets.

Least privilege for the agent and every tool

Give an agent only the tools required for its task. Prefer narrow operations such as “read the status of this deployment” over open-ended capabilities such as “run an arbitrary command.” Separate read and write actions, scope access to the required records or resources, and use distinct identities when tools have different risk levels.

Authorization must also be enforced by the downstream service. Hiding a tool from the model or describing a restriction in a system prompt is not an access-control boundary. The database, API or business service should verify that the presented user or workload identity is allowed to perform the requested action on the specific resource.

Short-lived, isolated credentials

Do not place reusable API keys in prompts, tool descriptions, source code or agent memory. Where supported, use managed identities or workload identity federation so credentials are issued through the platform and bound to a workload. Microsoft’s secretless authentication guidance describes managed identities for service-to-service access in supported Azure scenarios.

Some external systems still require a secret. Keep it in a managed secret store, scope its permissions and retrieval path, rotate it, and prevent it from entering model context or logs. Separate credential material by environment and workload so a development agent cannot inherit production access by accident.

MCP and tool permissions need explicit boundaries

Model Context Protocol (MCP) standardizes how clients and servers expose capabilities; it does not decide whether a particular user or agent should be allowed to invoke every tool. Register and review MCP servers, allowlist the tools each workload may use, and authorize sensitive calls at the server and downstream service. Document whether each tool reads, writes, deletes or triggers an external action.

For OAuth-protected MCP servers, validate tokens for the correct issuer, audience and scope. Do not blindly forward a client’s token to a downstream API. The MCP Security Best Practices warn that token passthrough can bypass controls and weaken accountability. Tool output and retrieved content should also be treated as untrusted input that may attempt to influence later actions.

Prompt injection can arrive through retrieved documents and tool responses, not only through a user prompt. Treat that content as untrusted data, but do not rely on labels or prompt wording as an authorization boundary. Validate proposed tool arguments and enforce the caller’s permissions in application code when the action executes; require action-specific approval when the consequences warrant it. OWASP’s prompt injection guidance describes these controls as layers because model-level filtering alone cannot establish that an action is authorized.

Separate runtime, tool and target boundaries

Keep the agent runtime, tool server and target system as distinct security boundaries. A tool server should receive only the identity it needs, and the runtime should not have direct access to every downstream credential. Restrict network egress to approved destinations where practical, isolate workloads by environment and risk, and ensure a compromise in one tool does not automatically grant access to another.

For multi-step work, do not let successful authorization for one operation imply authorization for all later operations. Re-evaluate access when the user, target resource, requested action or risk context changes.

Record the action path for audit and response

Operators should be able to reconstruct what happened: which user or workflow initiated the request, which agent and tool versions ran, what action was requested, which identity was used downstream, what authorization decision was made, whether an approval was granted, and what the target system returned. Correlate these events with request IDs and timestamps.

Audit does not mean storing every prompt or secret verbatim. Define redaction, retention and access rules for traces because tool arguments and results may contain sensitive data. Make it possible to revoke access, disable a tool integration or stop an agent workflow during an incident.

Use human approval for consequential actions

For actions that are irreversible, high impact or outside routine delegated authority, pause and ask an authorized person to approve the actual operation. Show the target system, affected resource, proposed change and material consequences. Bind the approval to that specific request and re-check authorization when executing it; a broad “approve this agent” choice should not become permanent authority.

Human approval is a risk control, not a substitute for least privilege or downstream authorization. Low-risk read-only tasks may proceed without an approval step, while financial, security, customer-impacting or production changes may need stronger review based on organizational policy.

Example: an agent that changes cloud infrastructure

Suppose an operations agent can inspect deployment health and propose a configuration change. Give it read-only access to health data and a narrowly scoped tool that can create a proposed change. Require a separate approval for applying the change to production. The apply step uses a deployment identity limited to the target scope, validates the approved plan, and records the caller, approver, plan and result. If the agent is prompted to make an unrelated change, the tool and deployment identity still deny it.

In this design, the model can help interpret a request and prepare work. Deterministic authorization remains in the application and connected systems. OWASP’s Excessive Agency guidance similarly calls out excessive functionality, permissions and autonomy, and recommends narrow tools, minimum permissions, user-context authorization and human approval for high-impact actions.

Make the safe agent path a platform capability

Organizations do not need every product team to invent a separate identity flow, MCP review, secrets pattern, audit schema and approval mechanism. Platform engineering can provide reusable agent runtimes, workload identity patterns, tool registration, authorization checks, credential isolation, policy, tracing and emergency controls.

Those shared capabilities should come with a clear contract: what identities are created, what permissions are granted, how a tool is approved, what events are logged, which environments are supported and who responds when something fails. Workload owners still define business purpose, data access and risk; the platform makes the control path repeatable and easier to inspect.

Tongtech’s Agentic AI Platform Architecture and Tool Governance guide covers runtime boundaries, tool mediation, approvals, isolation, observability and emergency controls. The AI Security, Identity and Responsible AI guide lays out broader AI security requirements. For the cloud and platform layers, see From Cloud Landing Zones to AI Landing Zones and The Enterprise AI Stack Is Becoming a Platform Engineering Problem.

Treat retrieved content and tool output as untrusted input

An agent can receive hostile or misleading instructions from a document, web page, ticket or tool response even when the user’s request is legitimate. Do not treat retrieved text as authorization to call a tool, and do not let a model’s natural-language explanation substitute for a policy decision. Validate tool arguments against a schema and the caller’s permissions, constrain destinations and operations with allowlists, and require a separate approval for consequential actions. Test prompt-injection cases in which untrusted content asks the agent to reveal data, change permissions or bypass its task. Log enough context to investigate decisions while minimizing sensitive prompt and response retention. This defense in depth matters because a prompt or retrieval filter cannot reliably establish the authority for a transaction. The target system must still authenticate the caller and enforce its own authorization, while the agent runtime limits which actions can be requested and records the result. For high-impact tools, make the approval request show the intended target, arguments and expected effect, then bind the approval to that exact operation. If the agent changes the request after approval, require a new decision rather than reusing the earlier consent.

Continue reading

References

Planning agents with access to enterprise tools?

Start with an AI identity and agent security review.

Map agent identities, tool permissions, delegated access, credential boundaries and approval paths before connecting production systems.

Plan an agent security review