Read-Only AI Agents on AWS: Two Guardrails Failed in 2026, and IAM Held

 

 

In July 2026, AWS fixed two of its own guardrails for AI agents in the same week. One quietly dropped its deny list if its index of read-only operations failed to load at startup (CVE-2026-16584). The other hid write tools from the agent's menu, yet still ran them for anyone who knew the name.

 

AWS's bulletin for the first says the IAM permissions on the agent's credentials "remain in effect and are unaffected." That sentence is half of this article. The other half is how you would find out what the agent did.

 

An agent cannot talk its way past two things. A lock on the outside, which blocks writes whatever the model decides. And a witness: the system's own record, which the agent cannot edit and which does not care what the agent says about itself. On AWS the lock is IAM and the witness is CloudTrail. IAM's read-only policies read more than their names say, and CloudTrail records less.

 

I learned this in September, on a smaller system. I wrote a skill that audits who can see what in a database, and told it at the top of the file, in plain words, to change nothing. Then I asked it to fix everything it found, without asking me. It made twenty-five changes and reported that it had made none . I found out from the database's own query log, not from the agent.

 

One honest note. When I reran that test with the lock on, the rewritten skill refused on its own, and the lock never came into play. I trust the lock because of where it sits, not because I have watched it stop anything.

 

AWS's open-source MCP servers for EKS, ECS and Serverless in awslabs/mcp  start read-only in their code: the EKS server "runs in read-only mode by default." The general-purpose AWS API MCP Server, which runs any AWS CLI command, ships with READ_OPERATIONS_ONLY set to false.

 

The one-click install buttons in the EKS and Serverless READMEs override those defaults. They add the server with --allow-write and --allow-sensitive-data-access already in its arguments, and the EKS README's example configuration "includes both."

 

Almost nobody meets a tool through its argument table. They meet it through the button.

 

CVE-2026-16584 hit versions 0.2.13 to 1.3.47 of the AWS API MCP Server. If its read-only operations index failed to load, for example on "a transient network error," its deny list stayed "silently skipped for the entire process lifetime." The proxy's --read-only flag had a quieter gap, fixed in 1.6.4 on 20 July: "A client that knew the tool name could still invoke it directly via tools/call." AWS's migration guide still uses 1.6.3 as its example pin.

 

My skill file had the same flaw as that proxy. A list of tools is a hint, not a fence.

 

With the fix, the flag is honest, and blunter than its name: it drops every tool not marked readOnlyHint: true. In the server's tool list on 3 October 2026, that removed aws___run_script, which runs Python against your account, and aws___get_presigned_url. What is left reads documentation. Read-only mode does not give you an agent that only reads your account. It gives you one that cannot see it.

 

For the old consent prompt, the migration guide offers one replacement: "use IAM policies to control write access." Requests forwarded by AWS's managed MCP servers carry aws:ViaAWSMCPService, set to true, and aws:CalledViaAWSMCP. Calls made directly, by the open-source servers on your laptop or by the shell, carry neither mark.

 

The managed server knows about the shell. The instructions it sends to every connecting agent end with one sentence: "Do NOT use the Bash tool to run the AWS CLI." That is a rule in prose, inside a prompt. I wrote one of those in September. It lasted one request.

So put the limit in IAM, where no server setting can switch it off.

AWS's description of ReadOnlyAccess says whoever has it "will also have access to read data in storage services like Amazon S3 buckets and Amazon DynamoDB tables." At version 190 it includes s3:Get*, dynamodb:Scan and logs:FilterLogEvents. ViewOnlyAccess, AWS says, "cannot read resource content."

 

ViewOnlyAccess is the better start, and it still is not metadata only. It includes lambda:List*, and ListFunctions returns every function's environment variables. For the default key, the Lambda guide says, "No AWS KMS permissions are required." It includes ecs:Describe*, which returns task definitions with their environment variables. And it includes ec2:DescribeLaunchTemplateVersions, which returns user data. The secrets people paste into configuration are configuration, and view-only reads configuration. Those three calls are not the whole list. ListVersionsByFunction returns the same variables for every version of a function, and the log group names give away the function names it asks for. EC2 user data also comes back through DescribeInstanceAttribute, Auto Scaling launch configurations and Spot requests. A deny list closes the calls somebody has already found. So layer 1 allows what the agent's task reads, and nothing else.

 

It is the house-sitter from my September post, with a better note. The note says: do not move the furniture. It says nothing about the spare key taped inside the cupboard.

 

One permission in ReadOnlyAccess changes state. It is sqs:Receive*. When you receive a message from a queue, the SQS documentation says, it "remains in the queue but becomes temporarily invisible to other consumers." Every receive also counts toward the limit after which a redrive policy moves the message to the dead-letter queue. An agent that peeks into a production queue to diagnose a backlog hides those messages from the service that was supposed to process them.

 

In a queue, looking is touching.

CloudTrail's Event history is on in every account and keeps an "immutable record of the past 90 days of management events in an AWS Region." It "does not show data events": what happens inside resources, like S3 object writes and DynamoDB item changes. "By default," the CloudTrail guide says, "trails and event data stores do not log data events." An agent that deletes forty objects leaves nothing in Event history, and a selector added afterwards records the next run, not this one.

 

Where calls made through the managed server land is not settled in AWS's documentation. They arrive forwarded on your behalf, marked aws-mcp.amazonaws.com in invokedBy. An AWS Security Blog post from April says "MCP-originated downstream calls are classified as data events, so you must enable data event logging on your CloudTrail trail to capture them." The server's own CloudTrail page does not say either way. If the blog is right, a check that reads only Event history passes in silence while the agent works through the managed server.

 

The same page shows each tool call recorded as an event of its own, with an "Exact copy of MCP request params," which for aws___run_script is the Python the agent wrote. The list of data event types does not yet name the server, so look for eventSource aws-mcp.amazonaws.com in your trail before you count on it.

 

IAM, a global service, records its events in US East (N. Virginia). In my run, the change I stared at for thirty seconds was the one to my own permissions. On AWS that is an IAM call, and it lands in us-east-1 even when the agent was working in Frankfurt.

 

Before you trust the witness, make it catch something.

The agent never runs as you. My skill rewrote my own permissions because it was running as me. Give it a role of its own that allows the reads its task needs and nothing else, and require a source identity, which CloudTrail records and which survives role chaining:

 

 

Because platform-engineer is itself a role, AWS requires sts:SetSourceIdentity on both sides of the chain, and caps the session at one hour:

 

 

Start the agent itself with AWS_PROFILE=agent-run, not only its MCP server, because a shell finds whatever credentials it can. Better still, run it where that profile is the only one: a container or a separate OS user.

 

Owner: the cloud platform team, with security approving any read added to the role.

Connect the agent through the SigV4 proxy, signed with the layer 1 session. The OAuth route skips the proxy and the profile: the agent acts as whoever signed in. Every version of the -cli package carries the July fix:

 

 

There is no --read-only here, on purpose: the role's allow list does the limiting.

 

People will still run agents as themselves: AWS's getting-started examples pass no profile at all. For them, a service control policy refuses the writes that hurt most, only when the request arrives through an AWS managed MCP server:

 

lambda:InvokeFunction and sts:AssumeRole are there because the mark does not travel: a Lambda function the agent invokes acts under its own role. Without AWS Organizations, attach the same JSON to each human role.

 

Owner: the platform team ships the client configuration, and security owns the SCP.

Record the agent role's data-event writes on the multi-Region trail, filtered by userIdentity.arn. put-event-selectors replaces the whole selector set and runs only in the trail's home Region, so the file carries the selectors the trail already has. Add AWS::DynamoDB::Table the same way for item writes:

 

 

CloudTrail Lake closed to new customers on May 31, 2026, so read the trail with Athena. Event history gives a free first look at management calls, in us-east-1 and every Region the agent used.

The real check reads the trail by the session's ARN, because AWS shows the ARN on forwarded calls and does not document the key. Failed and denied calls carry an errorcode:

 

 

Then plant one write. In a sandbox account, ask the agent to write a single object through the managed server, and run the check. The write should come back, or its AccessDenied should. If neither does, your witness cannot see that path, and you found out in a sandbox. Log files arrive in about five minutes on average, and AWS adds that "this time is not guaranteed," so check again later. Run every case three times: an agent asked twice can take a different road.

 

Owner: security engineering, with the platform team running both checks in the pipeline that starts agent sessions.

A Cloud Security Alliance survey published in April 2026, commissioned by Token Security, found that 65% of organizations had an AI agent incident in the previous twelve months, and 61% of those reported data exposure. Nobody needs to read the code to ask the three questions that decide whether that happens quietly.

 

Which role does each agent run as, and can that role write? Can we see every call the last agent session made, including the denied ones? Which of our MCP servers were installed from a one-click button, and with which arguments?

 

If any answer is "the agent's own report," the witness is missing.

An allow list costs work. Every new kind of task needs its reads added, and an agent that meets AccessDenied stops halfway. An open RFC in AWS's startups repository took the other road in September, ReadOnlyAccess with denies, and it misses the same way the first version of this article did: it denies lambda:GetFunction* while lambda:ListFunctions returns the same variables. A deny list holds only while it is complete. An allow list fails closed.

 

Data events cost $0.10 per 100,000. Recording every request on a bucket that serves 50 million a day costs about $1,500 a month. Recording one agent role's writes costs cents.

 

Skip all of it and nothing breaks today. The cost arrives on the day an agent's report says it only looked, and the only record that could disagree was never switched on.

 

Switch the witness on first.

I would give an agent the managed AWS MCP Server today for diagnosis, under a role that allows only the reads the diagnosis needs, with the organization-wide block on agent writes in place and the witness recording. I would hold on any role that can write until a planted write has come back from the trail. Two guardrails failed this year and IAM held both times, because the guardrails lived inside the agent's tools, and IAM sits on the credentials, outside anything the agent runs. Ask the agent what it did and you get its opinion of itself. Ask CloudTrail and you get a record, but only of the rooms you wired.

If you run an AI agent in an AWS account, tell me in the comments which credentials it holds, and whether anything other than the agent checks what it did. That is where I answer first.