This is post #2 of the . The agent had full database admin credentials because the developer gave it broad access "for convenience." Claude Opus 4.6 decided a cleanup was needed. Nine seconds. Gone. This is what excessive agency looks like in production.
2. Tool Poisoning (MCP Descriptor Manipulation)
An attacker compromises the tool interface itself, the MCP tool descriptors, schemas, metadata, or routing information. The agent invokes a tool based on falsified capabilities. The tool looks legitimate, the description says it does one thing, but it does something else entirely.
This is different from supply chain attacks (ASI04) because the tool itself hasn't been replaced. Only its interface description has been manipulated at runtime.
3. Loop Amplification
A planner agent repeatedly calls costly APIs without realizing it. No attacker needed. The agent just gets stuck in a retry loop, calling the same expensive API over and over. Your bill spikes. Your rate limits get exhausted. Your downstream services get DDoS'd by your own agent.
4. Tool Chaining for Exfiltration
An agent chains together individually safe tools into a dangerous sequence: read from CRM → format as CSV → send via email tool. Each step is legitimate. The sequence is data exfiltration.
Real example from OWASP: A security automation agent gets tricked into chaining PowerShell, cURL, and internal APIs to exfiltrate logs. Because every command is executed by trusted binaries under valid credentials, EDR/XDR sees no malware and the misuse goes undetected.
Real incident: In July 2025, Noma Security disclosed in August 2025. By injecting prompts into code files the agent processed, he made it leak secrets (API keys, environment variables) through DNS resolution requests. Every tool call was "approved." The exfiltration channel was invisible to application-level monitoring. AWS patched it (, extending them to multi-step agentic workflows. Here's how to implement each one on AWS.
1. Per-Tool Least Privilege with IAM
This is the single most impactful mitigation. Instead of giving your agent a broad IAM role, create separate policies per tool that limitdkvruufvgucebjirtuevvjcdcbdeericvj
AWS just dropped a blog on enforcing least-privilege authorization in multi-agent AI chains using Cedar
(, action groups are your primary defense against tool misuse. Each action group defines:
Which API operations the agent can call (explicit allowlist)
The OpenAPI schema that constrains parameters
A separate is your circuit breaker:
Usage plans and throttling - Set per-agent rate limits. If your agent shouldn't call an API more than 10 times per minute, enforce that at the gateway level, not in the agent's prompt.
Request validation - Validate request bodies against your OpenAPI schema before they reach your backend. Malformed parameters get rejected before they can cause damage.
metrics with Lambda concurrency limits:
- Track per-tool invocation counts and costs as CloudWatch custom metrics
- Set alarms that trigger when an agent exceeds its tool budget
- Alarm action: invoke a Lambda that revokes the agent's session credentials via IAM
CODEalarm = cloudwatch.put_metric_alarm(
AlarmName=f"agent-tool-budget-exceeded-{agent_id}",
MetricName="ToolInvocations",
Namespace="AgentSecurity",
Dimensions=[{"Name": "AgentId", "Value": agent_id}], # scope the budget
Statistic="Sum",
Period=300,
EvaluationPeriods=1,
Threshold=50,
ComparisonOperator="GreaterThanThreshold",
TreatMissingData="notBreaching",
AlarmActions=["arn:aws:lambda:us-east-1:123456789012:function:revoke-agent-session"],
)
# Required or the action silently no-ops:
lambda_client.add_permission(
FunctionName="revoke-agent-session",
StatementId=f"cw-alarm-{agent_id}",
Action="lambda:InvokeFunction",
Principal="lambda.alarms.cloudwatch.amazonaws.com",
SourceArn=alarm_arn, # the alarm's ARN
)
And the Lambda's revocation logic:
iam.put_role_policy(
RoleName=agent_role,
PolicyName="AWSRevokeOlderSessions",
PolicyDocument=json.dumps({
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny", "Action": "*", "Resource": "*",
"Condition": {"DateLessThan": {"aws:TokenIssueTime": now_iso}}
}]
}),
)
5. Per-Invocation Scope-Down with Session Policies
Your agent already uses an IAM role. But that role stays active for the entire session - which can be up to 12 hours. The role's permissions cover everything the agent might need across all its tools.
The tighter pattern: issue a further-scoped session credential per tool call, with an inline policy that limits access to just the resources this specific invocation needs. Duration: minutes, not hours.
CODEimport json, re, boto3
sts = boto3.client("sts")
account = "123456789012" # 12-digit account id, not 9
# STS session names must match [\w+=,.@-] and be <= 64 chars
session_name = re.sub(r"[^\w+=,.@-]", "-", f"agent-{session_id}-{tool_name}")[:64]
# Issue credentials that last only 15 minutes, scoped to this specific action
creds = sts.assume_role(
RoleArn=f"arn:aws:iam::{account}:role/agent-order-lookup",
RoleSessionName=session_name,
DurationSeconds=900, # 15 min (also the STS minimum)
Policy=json.dumps({
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "dynamodb:GetItem",
"Resource": f"arn:aws:dynamodb:us-east-1:{account}:table/orders",
"Condition": {
"ForAllValues:StringEquals": {
"dynamodb:LeadingKeys": [customer_id]
}
}
}]
}),
)["Credentials"]
# Actually use the scoped creds
ddb = boto3.client(
"dynamodb",
aws_access_key_id=creds["AccessKeyId"],
aws_secret_access_key=creds["SecretAccessKey"],
aws_session_token=creds["SessionToken"],
)
The inline
Policyparameter narrows the assumed role further. Even if the role itself allows broader DynamoDB access, this session can only read this specific customer's records. And if the agent gets tricked into a chaining attack, the credentials expire in 15 minutes anyway.
6. Behavioral Monitoring for Tool Chaining
The hardest pattern to catch: individually legitimate actions that form a malicious sequence. Use - What happens when agents inherit user sessions, accumulate privileges across delegation chains, and act as confused deputies. Plus how Amazon Verified Permissions (Cedar) gives you fine-grained control over what agents can do on behalf of whom.
I would be very interested to hear your thoughts or comments, so please feel free to ping me on , or drop them below. If you've built agents with scoped tool access, I'd love to hear your approach.
Onward!!
↗ Original-Artikel auf dev.to lesenVollständiger Original-BerichtAusführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.
SOCIAL SHARE CARD GENERATOR