Identity-first segmentation for AI agents

An agent inside your VPC with a long-lived service account is functionally a privileged insider. Segmentation slows lateral movement but does not change the blast radius of the credential itself. If the agent can be steered by a prompt injection or a poisoned document to take actions it should not, the network position is irrelevant; the credential is what permits the action and the credential is what an attacker is targeting.

Identity is where the control belongs. Per-agent identities, capability tokens scoped to a single tool call, and attestation that the requesting agent is the one the orchestrator dispatched together produce a control plane in which a compromised agent can do exactly the work it was dispatched to do and nothing else. The control plane has costs — orchestration complexity, latency on token issuance — and the costs are worth paying for any agent whose actions could materially harm a customer or the business.

The segmentation conversation often distracts from the identity conversation because segmentation has a longer institutional history and a more developed vendor ecosystem. Programs that allow the distraction end up with carefully segmented networks and unchanged identity practices, which produces an architecture that looks rigorous on a diagram and behaves like the original perimeter in practice. The leadership move is to insist that identity gets the same air time as segmentation in the agent architecture review, and that the architecture is judged on the identity posture first.

The implementation pattern that has worked in enterprise deployments has three parts. An identity broker that issues short-lived tokens per agent invocation, scoped to the specific tool the orchestrator has determined the agent needs. An attestation step that proves to the tool that the requesting agent is the orchestrator's dispatch, not a replay or a forgery. And a decision log that captures the dispatch, the scope, the attestation, and the action, with the chain queryable as a single record.

The investment is real but bounded. Most enterprises that have made it report that the dominant cost was the orchestration refactor, not the identity primitives, and that the refactor produced unexpected gains in operability and incident response. The identity hardening was the obvious benefit; the operational improvements were the surprise that paid for the work.

The token issuance path has to be hardened against the failure modes that traditional identity brokers were not designed for. Agents request tokens at orders of magnitude higher rates than humans, with patterns that defeat the rate limits that protect traditional flows. The broker has to be sized for the agent load and instrumented for the agent-specific anomalies — a spike in tool diversity from a single agent, a sudden change in the geographic distribution of token requests, an unexpected pattern of denied requests followed by successful ones with subtly different scopes. The agent-specific anomalies are different from the human-specific anomalies, and the broker has to surface both classes.

The orchestrator is the component that most often becomes the weak link in this architecture, because it sits between the user and the agent and holds the authority that the per-call tokens derive from. A compromised orchestrator can issue legitimate-looking dispatches with malicious scopes, and the downstream tokens will be valid even though the underlying intent was hostile. The orchestrator therefore needs the same level of protection as a high-privilege service account in the traditional architecture: hardened access, strong attestation, comprehensive logging, and a regular review of the dispatches it has produced.

Programs that treat the orchestrator as just another service tend to under-invest in its protection, on the assumption that the per-call token model is the security boundary. The assumption is partially correct but misses the orchestrator's role as the issuer of intent. The mature pattern treats the orchestrator as a tier-zero asset and protects it accordingly, while continuing to derive specific authority from the per-call tokens. The two layers reinforce each other; either layer alone is weaker than the combination.

The pragmatic starting point is the highest-risk agent in production. Inventory its tool set, its current identity, and its blast radius. Replace the shared service account with a per-invocation identity and scoped tokens for one tool, observe the operational impact, and expand from there. Treating the work as a multi-quarter platform investment rather than as a one-time hardening produces a substrate that the rest of the agent estate can migrate to as it is built.

The migration sequence that has worked in practice prioritizes agents by the cost of a compromise rather than by the ease of the migration. The hardest agents to migrate are usually the ones that need the migration most, because they are the ones whose tool sets are broadest and whose blast radius is largest. Starting with the easy agents produces a misleading sense of progress and leaves the highest-risk surface unchanged. The leadership task is to commit to the harder sequencing and to defend it against the natural pressure to show quick wins on the easier agents first.

Once per-agent identities are in place, the next layer of defense is behavioral. An agent that suddenly requests tokens for tools it has never used, at volumes that diverge from its historical pattern, or from origin processes that do not match its declared host, is producing the signals that traditional user-behavior analytics would flag for a human principal. The same techniques apply to agents, with the parameters tuned for the higher request rates and tighter time windows that agent traffic exhibits. Programs that wire the agent telemetry into their existing UEBA pipelines with appropriate tuning find that compromises and misconfigurations surface in hours rather than weeks.

The baselines also surface design problems that are not compromises. An agent whose scope is creeping — accumulating tool permissions over time as engineers add capabilities without removing the old ones — produces a behavioral signature that the baseline will eventually flag. The flag is an opportunity to revisit the agent's design and to prune the permissions back to what the current use case actually requires. Programs that treat the baseline as a security tool only miss the design feedback; programs that treat it as a feedback loop into the agent's design get both the security and the operational improvement.

The architectural payoff of per-agent identity arrives the first time an agent has to be revoked under incident conditions. Programs that have invested in the substrate can revoke a single agent's authority in seconds without affecting any other workload, with the revocation visible in the audit log and the affected callers receiving clear failure responses that route them to a human path. Programs that have not invested find that revoking an agent requires rotating shared credentials, restarting dependent services, and accepting collateral disruption to unrelated workflows during an already stressful incident.

Revocation has to be a rehearsed capability, not a theoretical one. The mature programs we have observed conduct quarterly drills in which a randomly selected production agent is revoked during a controlled window, with the response team measured on time-to-revoke, completeness of the propagation, and the quality of the user-facing communication that accompanied the revocation. The drills surface gaps that no design review would find, and the corrections that follow the drills are what produce real readiness for the unplanned revocations that will eventually be necessary.