When Your AI Agent Becomes the Insider Threat: Least Privilege at Machine Speed
How over-privileged AI agents create machine-speed insider threats, with practical IAM scoping patterns and the AgentCore defense architecture to prevent them.
Here is a stat that should stop every builder mid-deploy: by 2028, 25% of enterprise security breaches will trace back to AI agent abuse . Not prompt injection. Not model hallucination. Agents exercising permissions they should never have had. This is not some distant, theoretical risk. In April 2026, Palo Alto Networks' Unit 42 team disclosed what they called "Agent God Mode" , a set of over-privileged default IAM configurations in the AWS AgentCore Starter Toolkit that could let a compromised agent read and poison every other agent's memory, pull arbitrary container images, and invoke any Code Interpreter in the account.
We have seen this movie before. A decade ago, we were shipping EC2 instances with
AdministratorAccess because IAM was "too complex" to get right under deadline pressure. The breaches that followed (Capital One's misconfigured WAF and SSRF chain , the SolarWinds supply chain compromise , and countless S3 bucket exposures ) taught us painfully that over-privilege is a design flaw, not an operational detail. Now we are making the same mistake again, but at machine speed, with principals that reason dynamically, chain tool calls autonomously, and never sleep.The window to get this right is closing fast. Let's talk about why AI agents are fundamentally different from any principal class IAM was designed for, and what to do about it.
Why AI Agents Are a New Principal Class
Let's be precise about what we are dealing with. AI agents are not humans. They are not traditional services. They occupy a new category entirely, and our security models have not caught up.
Agents are not humans, and they are not services. A Lambda function calls the same APIs in the same order every time. A human browses slowly, reads context, and makes judgment calls. An agent reasons dynamically: it observes state, plans multi-step tool chains, and executes them at API speed. A single agent invocation might read from DynamoDB, call an external MCP server , write to S3, and invoke another agent, all within a two-second execution window. There is no "click-through consent" moment. No time for a human to notice something looks wrong.
The scale of the problem is not hypothetical. According to a March 2026 report from HelpNetSecurity , 80% of organizations that have deployed AI agents reported observing risky agent behaviors, including unauthorized data access, unexpected lateral movement between services, and agents persisting credentials beyond intended session boundaries. Separately, Obsidian Security research confirmed that credential inheritance, orphaned agents, and unsanctioned MCP server connections represent the highest-severity risk factors in enterprise deployments today.
Here is the core architectural issue: IAM was designed for enumerated principals. It assumes you know, at policy-authoring time, exactly what actions a principal will take and what resources it will touch. Agents violate this assumption entirely. Their behavior is emergent, shaped by prompts, tool definitions, retrieved context, and conversation history. The same agent with the same IAM role might call completely different APIs depending on what the user asked. As one researcher put it, agents represent "the principal class your IAM model never enumerated" .
This means an agent's true blast radius is not the single API call you are thinking about. It is the union of ALL permissions it inherits across every possible reasoning path. If your agent's role allows
bedrock:InvokeModel, s3:GetObject, dynamodb:PutItem, and ecr:GetDownloadUrlForLayer, then a compromised agent can exercise all of those capabilities in any combination, at machine speed, without human review. Goml's Rogue Agent Impact Visualizer demonstrates how agents "don't just use permissions one at a time. They chain them. They orchestrate."We need to stop treating agents like slightly fancier Lambda functions. They are a new principal class, and they demand new security architecture.
Anatomy of "Agent God Mode"
In April 2026, Palo Alto Networks' Unit 42 published a detailed disclosure targeting the AgentCore Starter Toolkit, the quick-start template many builders use to bootstrap their first agentic applications on AWS. The findings were a masterclass in how builder-convenience defaults create security nightmares.
The Setup: The Starter Toolkit auto-creates IAM roles with wildcard permissions to reduce friction during development. These included policies like:
arn:aws:bedrock-agentcore:*:memory/*granting read/write access to all agent memory stores in the accountarn:aws:ecr:*:repository/*granting pull access to any ECR repositoryarn:aws:bedrock-agentcore:*:code-interpreter/*granting the ability to invoke any Code Interpreter session
The Attack Chain: Unit 42 demonstrated that compromising a single agent (through prompt injection , a malicious MCP tool, or a poisoned retrieval document ) could cascade across the entire account:
- Pivot to ECR. Pull any container image in the account using the agent's overly broad ECR permissions.
- Extract environment files. Container definitions often embed Memory Store IDs, API keys, and session configuration as environment variables baked into the image.
- Read all agent memories. Using the wildcard memory permission, the attacker reads conversation histories, RAG embeddings, and cached reasoning from every other agent in the account.
- Poison agent memories. Write malicious instructions into other agents' memory stores, creating persistent backdoors that survive agent restarts.
- Invoke Code Interpreters. Execute arbitrary code in any active interpreter session, pivoting to whatever permissions that interpreter's role carries.
AWS responded by updating documentation to explicitly warn that Starter Toolkit roles are "intended for development and testing environments only" . But let's be honest: how many builders read that warning? How many production workloads are running right now on "temporary" dev configurations that never got hardened? A June 2026 analysis from Obsidian Security confirmed that "Bedrock agents receive IAM roles scoped at the account level during initial setup, and those roles are rarely narrowed after the pilot phase."
The lesson here is structural, not just tactical. Developer toolkits are optimized for time-to-first-demo, not security posture. This is not a criticism; it is a design constraint. The shared responsibility model is unambiguous here: AWS secures the infrastructure; you own the configuration. If your agent is running with wildcard permissions in production, that is your breach, not theirs.
The Three Anti-Patterns That Create Over-Privileged Agents
After reviewing dozens of agent architectures across customer engagements, I see the same three anti-patterns repeatedly. They are not exotic. They are born from familiar pressures: deadlines, complexity, and the reasonable human desire to just make the thing work.
Anti-Pattern 1: Role Reuse
What it looks like: One IAM role shared across your customer-service agent, your data-analysis agent, and your code-generation agent, because creating and managing separate roles for each felt like unnecessary overhead.
Why it's dangerous: Your customer-service agent only needs
dynamodb:GetItem on the customer table. Your code-generation agent needs codecommit:GitPull. When they share a role, the customer-service agent also has CodeCommit access, and an attacker who compromises it through a prompt injection in a support ticket can now read your source code. ARMO Security research found that "when teams reuse an existing role across multiple agent types because creating a new one is friction, the blast radius of every agent becomes the union of every agent's capabilities."The root cause: IAM role creation has historically been high-friction. CloudFormation templates get long. Permission boundaries feel obscure. So teams consolidate.
Anti-Pattern 2: Credential Inheritance
What it looks like: An agent running with credentials derived from a human user's session or a shared service account, typically because the agent needs to "act on behalf of" the user.
Why it's dangerous: That human session often carries permissions for dozens of services the agent never needs. A Solutions Architect's SSO session might include
iam:*, organizations:*, and sts:AssumeRole across the entire account. When your agent inherits that session, it inherits all of it. As Obsidian Security notes , "most enterprise AI agents carry excessive OAuth privileges, and most security teams cannot tell you which tokens those agents hold, how long they have been active, or whether any of them have already been abused." A real-world example: in April 2026, attackers compromised an IAM role used for platform integration , created an administrator user, and moved laterally across 19 AWS accounts by exploiting trusted role relationships.The root cause: Delegation is hard. Building proper credential vending (where the agent receives only the subset of permissions required for the current task) requires upfront architecture that is easy to skip when shipping fast.
Anti-Pattern 3: Session-Scoped Ambient Authority
What it looks like: An MCP server receives a single OAuth token at session start, and that token grants access to its entire tool surface (20, 30, even 50 tools) with no per-invocation scoping.
Why it's dangerous: The agent might only need
read_email for the current request, but the token also authorizes send_email, delete_calendar_event, and modify_contacts. If the agent's reasoning is manipulated mid-session through indirect prompt injection in a retrieved document, it can exercise any capability the token covers. Research from Tianpan.co describes how "MCP's permission model works roughly like this: when an agent connects to a server, the session is authorized with OAuth scopes that cover the server's entire tool surface. A server exposing twenty tools receives a single token that grants access to all of them."The root cause: The MCP specification is still maturing. OAuth scoping per-tool is not natively supported in most MCP implementations today. Builders use a single broad token because the protocol does not make fine-grained scoping easy yet.
Defense Architecture: Building Least Privilege for Agents
Enough about the problem. Let's build. The following architecture is not theoretical. These are patterns available on AWS today, specifically designed for agentic workloads.
Per-Agent, Per-Task IAM Roles
The single most impactful change: one IAM role per agent action group, scoped to specific resources with conditions.
Here is a concrete example. Say your agent has a "memory recall" action group that reads from a specific AgentCore Memory Store. Instead of
bedrock-agentcore:*:memory/*, scope it:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ScopedMemoryRead",
"Effect": "Allow",
"Action": [
"bedrock-agentcore:GetMemory",
"bedrock-agentcore:SearchMemory"
],
"Resource": "arn:aws:bedrock-agentcore:us-east-1:111122223333:memory/customer-support-memory-store",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/AgentId": "customer-support-agent-v2",
"bedrock-agentcore:MemoryNamespace": "session-context"
}
}
}
]
}
Notice:
- Specific resource ARN, not a wildcard. This agent can only access its own memory store.
- Action scoping is read-only. No
PutMemory, noDeleteMemory. - Condition keys ensure only this specific agent can assume this role. The
MemoryNamespacecondition further restricts access to session-scoped memories, not long-term knowledge bases.
Yes, this means more roles. Use infrastructure-as-code. CDK constructs and Terraform modules can generate per-agent roles from a manifest. The operational cost is front-loaded; the security payoff compounds over time.
AgentCore Gateway and Lambda Interceptors
Amazon Bedrock AgentCore provides a Gateway layer that sits between your agent and its tools. This is where you enforce deterministic controls that no amount of prompt engineering can bypass.
Policy Interceptors are declarative rules evaluated before tool execution:
- Block specific tool calls based on user identity, time of day, or resource sensitivity
- Enforce rate limits per agent per tool (an agent calling
DeleteObject10,000 times in a minute is not normal behavior) - Require approval workflows for destructive actions
Lambda Interceptors give you programmatic control for dynamic validation . They run custom code before or after each tool call, supporting payload enrichment, token exchange, and response filtering:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
def pre_tool_interceptor(event, context):
tool_name = event['toolName']
parameters = event['toolParameters']
agent_id = event['agentIdentity']['agentId']
if tool_name == 'memory_read':
target_store = parameters.get('memoryStoreId', '')
allowed_stores = get_allowed_stores(agent_id)
if target_store not in allowed_stores:
return {
'action': 'BLOCK',
'reason': f'Agent {agent_id} not authorized for memory store {target_store}'
}
if tool_name in DESTRUCTIVE_TOOLS and event.get('environment') == 'prod':
return {
'action': 'REQUEST_APPROVAL',
'approver': event['agentIdentity']['ownerAlias'],
'timeout_seconds': 300
}
return {'action': 'ALLOW'}
The key insight: interceptors operate outside the agent's reasoning loop. The agent cannot talk its way past a Lambda interceptor. This is defense-in-depth for principals that can generate persuasive text. For a deeper walkthrough, see the AWS blog on combining Policy and Lambda interceptors for geography-based access control .
Session Boundaries and Credential Scoping
Agents should never hold long-lived credentials. The architecture:
1. Short-lived STS credentials. Use
sts:AssumeRole with a maximum session duration of 15 minutes (or less for sensitive operations). When the session expires, the agent must re-authenticate. This creates a natural circuit breaker: even if credentials are exfiltrated, they expire quickly.2. Session tags for dynamic scoping. Pass context as session tags that IAM policies evaluate at runtime:
1
2
3
4
5
6
7
8
{
"Condition": {
"StringEquals": {
"aws:PrincipalTag/SessionPurpose": "customer-lookup",
"aws:PrincipalTag/CustomerId": "${aws:RequestTag/TargetCustomerId}"
}
}
}
This ensures the agent can only access records for the specific customer it is currently serving, not the entire customer table.
3. AgentCore Identity. Use AgentCore's native identity framework rather than passing human credentials through. Each agent gets a unique identity that can be independently audited, rotated, and revoked. No more asking "which human's session was the agent using when it accessed that S3 bucket?"
4. Approval gates for destructive actions. Configure the AgentCore Gateway to require explicit human confirmation before executing operations classified as destructive: deletes, writes to production databases, and external API calls that trigger financial transactions.
Detection and Monitoring
Least privilege reduces blast radius. Detection limits dwell time. You need both.
CloudTrail patterns for agent principals:
- Filter CloudTrail events by the agent's IAM role ARN
- Alert on
AccessDeniedevents, as they indicate the agent is attempting actions outside its scoped permissions (either a misconfiguration or a sign of compromise) - Monitor for unusual tool-call sequences: an agent calling
ecr:GetDownloadUrlForLayerfollowed bybedrock-agentcore:PutMemoryis the exact Agent God Mode attack chain
GuardDuty for cross-service chaining:
- Enable GuardDuty's runtime monitoring for AI workload protection findings
- Watch for
UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration, which signals that agent credentials are being used from outside the expected compute environment - Configure suppression rules tuned to your agent's expected API patterns so that anomalies surface clearly
Blast radius visualization:
- Use IAM Access Analyzer to model the effective permissions of each agent role
- Map which resources each agent can access versus which it actually accesses (the gap is your over-privilege surface)
- Integrate with Security Hub for centralized findings and automated remediation workflows
Production Readiness Checklist
Before shipping any AI agent to production, verify:
- Every agent has its own IAM role. No role is shared between agents with different responsibilities or trust boundaries.
- Wildcard resources are eliminated. No
Resource: "*"in any agent policy. Every permission is scoped to specific ARNs. - Memory stores are isolated. Each agent can only read/write its own memory namespace. Cross-agent memory access requires explicit, auditable grants.
- Credentials are short-lived. STS session duration is 15 minutes or less. No long-lived access keys anywhere in the agent's execution path.
- Destructive actions require approval gates. Any tool call that modifies production data passes through a human-in-the-loop confirmation or a deterministic policy interceptor.
- CloudTrail logging is enabled and alarmed. Agent principal ARNs are monitored for
AccessDeniedpatterns, anomalous API sequences, and volume spikes. - MCP server tokens are minimally scoped. OAuth tokens grant access only to tools required for the current session context, not the server's entire capability surface.
- Starter Toolkit defaults are removed. If you bootstrapped with any quick-start template, every auto-generated policy has been reviewed and tightened for production.
Closing: Treat Agents Like Contractors With Building Access
Here is my mental model: an AI agent is a contractor with a badge to your building. They are competent. They are helpful. They will get the job done fast. But you would not give a contractor a master key to every floor, every server room, every filing cabinet just because it is faster than issuing a scoped badge. You give them access to the floor they are working on, for the hours they are scheduled, with an escort requirement for sensitive areas.
We are at an inflection point. AWS is building the right primitives: AgentCore Identity , Gateway interceptors , session-scoped credentials , and Memory Store isolation . The tooling exists. The gap is not capability; it is builder adoption. It is the moment where you decide whether to spend the extra 30 minutes scoping that IAM policy, or ship with the wildcard because it is Friday and the sprint ends Monday.
The Gartner prediction is not a warning about some future technology we cannot control yet. It is a prediction about us, about builders choosing convenience over security under deadline pressure, at a scale where the consequences compound at machine speed.
Every agent you deploy with over-privilege is an insider threat you authored yourself. The breach will not come from some sophisticated zero-day. It will come from a wildcard policy you meant to tighten later, that an attacker reached through a poisoned document in your RAG corpus, that cascaded across your account in the two seconds before anyone noticed.
Scope your agents. Isolate their memories. Shorten their sessions. Monitor their behavior. The cost of getting this right is measured in hours of architecture. The cost of getting it wrong is measured in incident reports.
Start today. Your agents already have.
Cyril Stansell is an Associate Solutions Architect at AWS, focused on secure agentic architectures. The opinions in this article represent the author's technical perspective and do not constitute official AWS security guidance.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article