The security conversation around agentic AI usually starts with the model - alignment, jailbreaks, guardrails - and that is the wrong end of the problem. A model with no tools is a text generator; a model with your OAuth tokens is a privileged automation platform whose control logic can be socially engineered by anything it reads. The durable security work is not making the model unmanipulable, which nobody knows how to do. It is making manipulation not worth much - and that is a least-privilege problem, a discipline security teams have practiced for decades.
Put bluntly: agent security is identity and authorization security. The teams handling it well treat each agent as a workload with an identity, scoped credentials, an allowlisted toolset, and a monitored sandbox - and they get to reuse most of their existing zero-trust machinery to do it.
An Agent Is a New Kind of Service Account
The classic mistake, visible in most early deployments, is one long-lived API key with broad scopes shared by every agent session. That design turns a single successful prompt injection anywhere into tenant-wide access everywhere. The alternatives are all established practice:
- ▸Per-session, per-user credentials: The agent acts with the invoking user's permissions, obtained via token exchange, expiring in minutes. A hijacked session then leaks one user's slice for a short window, not a service account's kingdom.
- ▸Workload identity, not embedded secrets: Issue agent identities the way you issue them to services - SPIFFE or your cloud provider's workload identity - so credentials are attestable and revocable, and no secret sits in an environment variable waiting to appear in a trace log.
- ▸Scopes matched to the task, not the platform: An agent that files tickets needs create-issue on one project, not full API access. Coarse scopes exist for developer convenience; agents do not deserve convenience.
- ▸Budgets as a security control: Rate limits and spend caps per agent identity bound the damage of both runaway loops and deliberate abuse.
Tools Define the Attack Surface
A tool definition is a security policy written in JSON, and it deserves review like one. The difference between a search-records tool and an execute-sql tool is the difference between a contained incident and a database dump - the model behind them is irrelevant to that distinction.
Design tools narrow: parameterized operations with validated arguments, not generic escape hatches. Separate read tools from write tools so policy can treat them differently. Make destructive operations - delete, send, pay, grant - distinct tools that the runtime can gate behind human confirmation, rather than modes of a general tool the runtime cannot distinguish. And validate arguments server-side against the session's identity: the model choosing a customer-id parameter is not authorization, any more than a browser sending a user-id field is.
The MCP Supply Chain Problem
The Model Context Protocol made tools composable, which is excellent for engineering velocity and awkward for security, because it created a supply chain: third-party MCP servers now sit inside your agents' trust boundary. Two failure modes deserve specific attention. Tool poisoning - malicious or compromised servers embedding instructions in tool descriptions and outputs that the model dutifully reads - and the confused deputy, where a low-trust server's output steers the agent into invoking a high-trust tool on the attacker's behalf.
Treat MCP servers like any dependency with production access: pin versions, review descriptions at install and on every update (a changed tool description is a changed prompt), run community servers with their own minimal credentials rather than piggybacking on the agent's, and prefer an internal registry of vetted servers over ad-hoc installs. Cross-server flows deserve explicit policy: data read from an untrusted server should not flow into the arguments of a privileged tool without validation or human review.
Sandboxes and Egress: Contain the Inevitable
Assume some instruction stream will eventually steer your agent. What happens next is decided by runtime boundaries, not model behavior:
1. Execute agent code and shell tools in disposable sandboxes - containers with gVisor or Firecracker isolation - with no ambient cloud credentials inside. 2. Default-deny egress: agents reach allowlisted hosts only, which converts most data-exfiltration payloads into connection-refused log lines. 3. Mount the minimum filesystem, read-only where possible; the agent's workspace is not your build server's home directory. 4. Log every tool call with arguments, identity, and originating context, streamed to the SIEM - agents are the rare attacker that narrates its own actions. 5. Rehearse revocation: killing one agent identity's tokens should be a runbook measured in seconds, tested before you need it.
Blast Radius Is the Product Decision
Here is the forward-looking part: the ceiling on what you can let agents do is set by your authorization architecture, not by model quality. Organizations with scoped identities, narrow tools, and contained runtimes can say yes to higher-autonomy use cases - and capture the productivity - because a failure costs them an incident report instead of a breach notification. Organizations without them will either stall agent adoption in review committees or learn their blast radius empirically. Least privilege was always good engineering; agents have made it the price of admission.