Your AI agent needs a database connection string, an API key for the payment provider, SSH access to a staging server, and permission to deploy to Kubernetes. It needs these credentials now, not after a ticket is reviewed by the security team. And it needs them for the next eight hours while it works through a backlog of infrastructure tasks.
This is the security problem that nobody planned for.
Zero trust architecture was designed for human users and their devices. The principles are sound: never trust, always verify, assume breach, enforce least privilege. But the implementation patterns, session-based authentication, MFA prompts, device posture checks, assume an entity that can respond to a challenge. AI agents cannot pick up a phone for a push notification.
The principles still apply. The implementation needs to change entirely.
The Agent Credential Problem
Every AI agent in your infrastructure is a non-human identity that needs access to resources. In most organizations today, this access is provisioned in one of two ways, and both are wrong.
The shared service account. The agent uses a service account with broad permissions. This account was created months ago, has accumulated permissions over time, and nobody remembers exactly what it can access. The credentials are stored in an environment variable or a secrets manager, but they do not rotate frequently because rotating them would break the agent’s workflow.
The developer’s personal credentials. The agent runs with the developer’s own API keys and access tokens. This means the agent has every permission the developer has, including permissions the agent does not need. If the agent is compromised, the attacker has a developer’s access level.
Both approaches violate the most basic principle of zero trust: least privilege. The agent should have exactly the permissions it needs for the task it is currently performing, and those permissions should expire when the task is complete.
Least Privilege for Non-Human Actors
Implementing least privilege for AI agents requires a different approach than implementing it for humans. Humans have roles. They are a developer, or an SRE, or a DBA, and their permissions reflect their role. Those permissions change infrequently.
AI agents have tasks. A single agent might write code in the morning, deploy infrastructure in the afternoon, and run database migrations in the evening. Each task requires a different set of permissions, and those permissions should be scoped to the task, not the agent.
Here is the model we use:
Task-scoped credentials. When an agent starts a task, it requests credentials for that specific task. The credential request includes what the task is, what resources it needs, and how long it will take. A policy engine evaluates the request against the agent’s authorization profile and issues short-lived credentials that expire when the task is complete.
Just-in-time access. The agent does not have standing access to any resource. It requests access when it needs it and relinquishes it when it is done. This is not a new concept. Privileged access management tools have supported just-in-time access for years. The difference is that AI agents make hundreds of access requests per day, so the provisioning system needs to be fast and automated.
Permission boundaries. Even within a task, the agent’s permissions are bounded. An agent tasked with deploying a new version of a service can update the deployment but cannot modify the service’s IAM role, cannot access other services’ secrets, and cannot make changes to the network configuration. These boundaries are defined in policy and enforced by the infrastructure, not by trusting the agent to stay within its scope.
Credential isolation. Each agent instance gets its own credentials. If you have five agents working on five tasks, you have five sets of credentials, each with different permissions. A compromised agent cannot use its credentials to access resources outside its task scope.
Audit Trails for Agentic Work
When a human engineer makes a change in production, the audit trail typically includes who made the change, when they made it, and what they changed. When an AI agent makes a change, you need more.
Attribution chain. Who authorized the agent to perform this task? Not just which user triggered the workflow, but which approval process was followed. If the agent deployed a new version, was that version reviewed and approved? By whom? The audit trail needs to connect the agent’s action to the human decisions that authorized it.
Decision context. Why did the agent make this specific change? If the agent chose to scale up a service, what data did it use to make that decision? What alternatives did it consider? This context is essential for post-incident analysis and compliance audits. An auditor who sees “Agent scaled service from 3 to 12 instances” needs to also see “because request latency exceeded the 200ms threshold defined in the scaling policy, based on 15 minutes of metrics data.”
Full replay capability. For any agent action, you should be able to reconstruct exactly what happened. What inputs the agent received, what prompts were sent to the model, what the model returned, and what actions the agent took. This is the AI equivalent of session recording for human users.
We built audit trails into CalliopeAI from the start because we recognized that AI workloads without audit trails are a compliance liability. Every model interaction, every decision, every action is logged with full context. Not because we anticipated regulatory requirements, but because debugging AI systems without audit trails is nearly impossible.
Credential Rotation for Agents
Credential rotation for service accounts has always been painful. Rotate the credential, update every system that uses it, verify nothing broke. With human-managed systems, this happens quarterly if you are disciplined, annually if you are not, and never if you are honest.
AI agents make rotation both more important and more feasible.
More important because agents are high-value targets. An AI agent with deployment permissions is worth compromising. The credentials it holds are powerful and used frequently. Long-lived credentials for agents are a risk that grows with every day they are not rotated.
More feasible because the rotation process can be automated end to end. The agent does not need to know its own credentials. The infrastructure provides them. When credentials rotate, the infrastructure provides new ones. The agent continues working.
The implementation looks like this:
Short-lived tokens over long-lived secrets. Instead of API keys that last indefinitely, issue OAuth tokens or AWS STS credentials that expire in hours. The agent’s runtime environment handles token refresh transparently. If a token is compromised, the exposure window is hours, not months.
Automated rotation with zero downtime. When a credential must be rotated, the system issues new credentials before revoking old ones. Both are valid during the transition window. The agent picks up the new credential on its next request. No restart, no downtime, no manual intervention.
Rotation triggered by usage anomalies. If an agent’s credential is used from an unexpected IP address, for an unexpected resource, or at an unexpected time, rotate immediately. Do not wait for the scheduled rotation. Anomaly-based rotation limits the blast radius of a compromise.
Network Segmentation for Agent Workloads
AI agents should run in isolated network segments with explicit allowlists for the resources they can reach. This is network-level least privilege.
The typical failure mode: an agent running in a developer’s environment has network access to everything the developer’s machine can reach. Internal wikis, other team’s services, production databases. If the agent is compromised through a prompt injection attack or a malicious dependency, the attacker inherits that network access.
The fix:
Dedicated agent networks. Run agents in isolated network segments, containers or VMs with network policies that restrict egress to only the resources the agent needs. An agent that deploys to Kubernetes needs access to the Kubernetes API and the container registry. It does not need access to the corporate wiki or the HR system.
Service mesh integration. If you are running a service mesh, extend it to include agent workloads. Mutual TLS between the agent and the services it accesses. Traffic policies that enforce the same least-privilege model at the network layer. Observability that shows exactly what the agent communicated with and when.
DNS-level control. Agents should only be able to resolve the hostnames they are authorized to access. This prevents data exfiltration through DNS tunneling and limits the blast radius of a compromise. If the agent cannot resolve the hostname of your secrets manager, it cannot reach it, regardless of what its credentials allow.
Threat Models Specific to AI Agents
AI agents face threats that human users do not. Your security model needs to account for them.
Prompt injection leading to unauthorized actions. An agent that processes untrusted input, user messages, web content, file contents, can be manipulated into performing actions outside its intended scope. This is not theoretical. It is a demonstrated attack vector. Mitigation: treat all agent inputs as untrusted, enforce permission boundaries at the infrastructure level, and monitor for actions that do not match the agent’s current task.
Training data poisoning through supply chain. An agent that pulls dependencies, reads documentation, or accesses code repositories can be influenced by malicious content planted in those sources. A carefully crafted code comment or README file can alter the agent’s behavior. Mitigation: pin dependencies, verify checksums, and treat all external content as potentially adversarial.
Credential exfiltration through output channels. An agent that generates code, writes logs, or produces reports might include credentials in its output. Not maliciously, but because it was exposed to the credentials during its work and the model included them in generated content. Mitigation: scan all agent outputs for secrets before they leave the agent’s environment.
Denial of service through resource exhaustion. An agent with the ability to provision resources can be manipulated into provisioning excessive compute, generating enormous API bills, or filling storage volumes. Mitigation: set hard limits on resource provisioning per task, per agent, and per time window. Alert on anomalies.
Implementation Roadmap
If you are starting from a typical setup with shared service accounts and minimal agent-specific security, here is a practical path forward.
Phase 1: Visibility. Inventory every AI agent in your infrastructure. What credentials does each one hold? What resources can it access? What is the blast radius if its credentials are compromised? This inventory is usually sobering.
Phase 2: Isolation. Move agent workloads to dedicated environments with network segmentation. This reduces the blast radius immediately, even before you implement fine-grained access control.
Phase 3: Short-lived credentials. Replace long-lived API keys with short-lived tokens. This is the highest-impact single change you can make. Even if the permissions are still too broad, limiting the credential lifetime limits the exposure window.
Phase 4: Task-scoped access. Implement just-in-time access provisioning for agent tasks. This requires a policy engine that can evaluate access requests against the agent’s authorization profile and the task’s requirements.
Phase 5: Continuous monitoring. Deploy monitoring that detects anomalous agent behavior: unexpected resource access, unusual action patterns, credential usage from unexpected locations. This is your ongoing defense against novel threats.
Each phase delivers incremental security improvements. You do not need to implement the entire model before seeing benefits. But you do need to start. Every day an AI agent runs with a shared service account and broad network access is a day your infrastructure is more exposed than it needs to be.
The zero trust principle has not changed: never trust, always verify. What has changed is who you are verifying. When your engineers include AI agents, your security model needs to treat them as first-class entities with their own identity, their own permissions, and their own threat profile. The alternative is pretending that an AI agent with a developer’s credentials is the same as a developer. It is not. And your security model should reflect that.
