Your Security Policy Wasn't Written for AI Agents

Your security policy was written with a specific actor model in mind: humans, services, and bots. Humans have accounts with MFA. Services have fixed IAM roles and service accounts. Bots are narrow, single-purpose tools with scoped access.

AI agents don't fit any of these categories cleanly. They're broader than bots. More capable than services. They make decisions that look human but operate at machine speed. And most organizations are running them under the actor model that happens to be most convenient — which usually means either the developer's personal credentials, or a "catch-all agent" service account with more access than any individual agent task requires.

Neither is appropriate. Both are quietly becoming a significant attack surface.

The actor model problem

When you write an IAM policy for a service, you know exactly what that service does. It's deterministic. You write a policy that matches its access requirements: this service reads from this S3 bucket, writes to this DynamoDB table, and nothing else. The policy is minimal because the behavior is known in advance.

When you deploy an AI agent, you often don't know exactly what it will do. It might read a config file it wasn't explicitly designed for. It might call an API that seemed relevant to the task. It might, given a particular prompt, do something entirely unexpected with the permissions you've granted it.

A static IAM policy built for a service assumes the service's behavior is constrained by its code. An agent's behavior is constrained by its instructions — and instructions are more porous than code.

Where current policies break down

Overprivileged agent identities. The path of least resistance for teams starting with AI agents is to run them under a developer's credentials or a generic service account. This works until something goes wrong, at which point you have no isolation between what the agent did and what a human developer might have done with the same credentials, no ability to revoke the agent's access independently, and no audit trail specific to agent actions.

No session or task scoping. Traditional access controls are identity-scoped: this identity has these permissions. For agents, you need task-scoped controls: this agent, for this task, has these permissions for this session. Your current IAM model almost certainly doesn't support this natively, so teams either don't implement it at all or build a custom layer that doesn't integrate with their existing policy enforcement.

Rotation schedules assume static consumers. You rotate secrets on a schedule — API keys every 90 days, database credentials quarterly. This model assumes a service that holds a credential for an extended period. Agents that spin up dynamically, use a credential for the duration of a task, and then stop create a different risk profile: frequent, short-duration credential use that your rotation schedule wasn't designed around. The right pattern is short-lived credentials scoped to the task, not long-lived credentials rotated on schedule.

Network policies assume stable behavioral baselines. Your network policies block unexpected outbound connections. An AI agent doing research might legitimately call APIs you didn't anticipate when you wrote the policy. An agent doing code refactoring might invoke a linting service not in your allowlist. The breadth of behavior that makes agents useful is the same breadth that makes static allowlists for them hard to maintain.

The threat model shift

The security model for services assumes: if the service is compromised, it will behave differently than expected. The anomaly detection is built around deviations from a deterministic baseline.

The security model for AI agents has to assume: the agent will behave non-deterministically even when not compromised. Variance is the baseline, not the exception.

This means the threat detection layer needs to change. You can't detect agent compromise by comparing behavior against expected behavior when expected behavior isn't precisely defined. You need a different signal: scope violations rather than behavior anomalies. Did this agent access credentials it has never touched in previous sessions? Did it make calls to services outside its task's normal domain? Did it exfiltrate data to an endpoint that isn't on the known-good list?

Scope-based detection is harder to tune than anomaly-based detection, but it's the right model for non-deterministic actors.

What updated policy looks like

This isn't a complete framework — it's the set of changes that have the highest leverage for most teams operating AI agents today.

Separate agent identities from human identities. Every agent should have its own identity, distinct from the engineers who build or operate it. Not a shared service account. An identity that is specifically attributed to agent use, so that agent actions are attributable in your audit logs and revocable independently of human access.

Issue task-scoped credentials at session start. Rather than giving an agent permanent credentials, generate short-lived tokens at the start of each agent session, scoped to the task at hand. Coding agent needs repo access: issue a token with read/write on that repo, no other permissions, with a TTL matched to typical task duration. The token expires when the task is done or when the TTL runs out, whichever comes first.

Build an agent policy layer. Your IAM policies define what resources an identity can access. You need a separate policy layer that defines what tasks an agent is authorized to perform. Not just "can this identity call this API" but "is this agent authorized to take actions in this domain for this task type." This is analogous to row-level security in a database: you have table-level permissions and row-level permissions. You need resource-level permissions and task-level permissions.

Require human approval gates for high-impact actions. Define a category of actions — production deployments, database writes in non-sandboxed environments, credential access beyond a specific scope — that always require human confirmation before the agent proceeds. Not as a workaround for an immature policy model, but as a permanent architectural constraint. Some decisions should always have a human in the loop.

Log agent actions at the tool-call level, not the session level. For compliance and forensics, you need the full sequence of actions an agent took in a session: every file read, every API call, every write. Session-level logs ("the agent completed task X") don't satisfy audit requirements for systems where agent actions have meaningful consequences.

The organizational gap

Most of the teams I've talked to who are shipping AI agent systems have their engineers thinking about these problems and their security teams almost completely separate from the decision. The security team wrote policies for services and humans. The engineers are building agents. Nobody is sitting at the intersection thinking systematically about what it means to run a non-deterministic privileged actor in a production environment.

That intersection is where the real risk lives. Not in the model being compromised or the vendor being breached — though those are real risks — but in the gap between the capabilities you've granted agents and the policy model you've applied to them.

The good news: you're early. The industry hasn't fully worked out the threat model for AI agents in production systems, which means you have the opportunity to get ahead of it rather than respond to an incident that forces the conversation.

That window won't stay open indefinitely.