When a coding agent works inside an AWS account, it usually does so with a human's permissions. It assumes an IAM role, and CloudTrail later shows that role's name — not the fact that a model was acting in a loop. That distinction moved this week from footnote to central problem, after two critical PHP flaws triggered a global patching wave and Cloudflare CEO Matthew Prince told Reuters to expect "a couple years where every single week it's going to feel like the sky is falling."

AWS did not make a speech about it. It quietly reorganised its tooling. The older AWS Labs repositories now carry deprecation notices; awslabs/startups, for instance, states that its plugins have moved to aws/agent-toolkit-for-aws. The Agent Toolkit is the supported product now: Apache-2.0, public since April, roughly 3,200 stars and just over 400 forks, last pushed on 23 October.

What is in it:

- Four plugins for Claude Code, Codex and Cursor (Kiro gets the MCP server directly): aws-core for service selection, CDK/CloudFormation, serverless, containers, storage, observability, billing and deployment; aws-agents for Bedrock and AgentCore; aws-data-analytics for S3 Tables, Glue and Athena; and aws-agents-for-devsecops for incident investigation, code review, UAT sign-off, vulnerability scanning and penetration testing through AWS DevOps Agent and AWS Security Agent. - Agent skills loaded on demand, plus rules files that tell an agent to search the documentation instead of guessing. - The AWS MCP Server: one managed, authenticated endpoint covering more than 300 services, with sandboxed Python execution, unauthenticated documentation search, CloudWatch metrics and per-request CloudTrail logging.

The interesting part is two IAM context keys: aws:ViaAWSMCPService and aws:CalledViaAWSMCP. AWS attaches them to calls that pass through its managed MCP servers. That lets you write a policy permitting an agent only read actions even when the underlying role could write — or permitting certain actions only when a human initiated them. This is not a sandbox and not a state machine. It is an identity layer: the request now carries who triggered it.

Why that is more than product housekeeping: the past fortnight showed how quickly an agent with permissions becomes an attack surface — not because it is malicious, but because it follows instructions written in a ticket, a README or a web page. If an agent can only read, a prompt injection is unpleasant. If it can deploy, the injection is an incident. Separating agent actions from human actions is the precondition for drawing a boundary at all.

What the toolkit does not solve:

- Within the permissions it was granted, a compromised agent is still dangerous. The condition key says who acted; it does not say the action was wise. - A devsecops plugin that can kick off penetration tests is itself a powerful tool. Whoever installs it should know which role it runs under. - The IAM keys apply to calls through the managed MCP servers. Teams running agents straight against the CLI or their own integrations do not get that distinction for free. - Logging is not policy. CloudTrail tells you afterwards what happened. A human still decides what an agent is allowed to do.

The practical consequence for teams is unglamorous: agents get their own roles instead of borrowed ones, policies get conditions instead of trust, and the question "what does this thing actually need" gets answered before the first deploy rather than after the first incident. AWS now supplies the building blocks — and the excuse that agents cannot be distinguished from humans is weaker this week than it was last week.

Sources