Build1 publisher3 min readPublished
AWS's one-minute test for agent access is really a test of where the answer lives
Amazon says you should be able to name every AI agent touching customer data in under a minute. Its own worked example explains why most teams cannot: the record is a file on a laptop.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- AWS says it asks customers which AI agents can reach customer data, who granted it, and what a leaked credential would expose, and expects an answer inside a minute.
- The failure it describes is a plaintext production database password in a teammate's mcp.json, beside a comment saying to rotate it.
- It names five structural breakdowns: credential sprawl, policy drift, audit gaps, cost opacity and shadow IT.
- Its arithmetic: ten assistants against five internal APIs means fifty hand-built credential sets, and fifty edits when one backend policy changes.
- The prescription is staged in four scopes, beginning with one governed door under SSO and CloudTrail and ending at multi-Region failover past 1,000 users.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint While secrets live in per-developer config files, the answer to the minute question is spread across machines no auditor can read, so the test cannot be passed by trying harder.
- decision AWS is telling buyers not to wait for the full stack, which turns the purchase into a scoping argument: which single scope do we need this quarter, and who signs off on skipping the rest.
- cost Spend attribution is bundled with the tool catalog, so a finance team that only wants per-team costs ends up funding developer self-service to get them.
- exposure An agent that keeps its own local config never appears in the gateway's decision log, so the inventory reads complete while the ungoverned path stays open.
A minute is roughly the time it takes to query a system that already knows. Anything longer means someone is messaging colleagues. In the failure AWS describes, the authoritative record of which agent can reach which backend is a file in a developer's config folder, sitting next to a plaintext production database password and a note to rotate it [2]. There are as many authoritative records as there are laptops, and the backend cannot help, because what arrives is a valid credential attached to a well-formed call.
That is the whole reason the framing moves from configuration to identity. A configuration problem is fixed by editing files. The fifty credential sets in AWS's own arithmetic [4] are each individually fixable and collectively unfixable, because the work scales with the product of assistants and backends [5]: double both and fifty becomes two hundred [15]. Brokered identity is fixed once, since "who is calling and under what authority" then has a single place to be answered, and a single place to be logged [7].
It matters that the clients here are IDE assistants like Kiro, Claude Code and Cursor [14]. Those are installed per developer, which is why shadow IT and credential sprawl appear on the same list of five breakdowns [3] rather than as separate stories.
Now the tension inside the post. AWS warns that most teams try to build the complete gateway before allowing any AI use, which takes months and ships the wrong thing [8]. Fair enough, but only Scope 1 answers the minute question: single sign-on, centralised credentials, CloudTrail [9]. Scope 2 answers a different one, who invoked which tool and when, and it wants Cedar policies, PII redaction and consent flows [10]. Read the maturity ladder as a queue and you will buy policy engines before you have an inventory to write policy against.
The sequencing bites hardest on money. Cost opacity is named as one of the five structural failures [3], but its remedy, per-tool cost attribution, is parked in Scope 3 alongside the registry and on-premises discovery [11], so the finance question waits behind a developer self-service feature [16].
And the file on the laptop still works. A single governed entry point governs the traffic that chooses to come through it [6]. Until backends refuse credentials the broker did not issue, mcp.json is a functioning bypass that produces no log line, which means the inventory can be complete and wrong at the same time.
The most honest passage is the one listing self-hosted substitutes: Kong Gateway, Open Policy Agent, NeMo Guardrails, LangFuse [13]. AWS is describing a control pattern it also sells. The pattern is the part you cannot skip.
What to watch
- Whether per-tool cost attribution becomes available without adopting the full catalog scope, since budget owners are the ones waiting on it.
- Whether AWS adds enforcement that makes backends refuse credentials the broker did not issue, which is what would close the local mcp.json bypass.
- Whether the self-hosted combination the post names gets a published reference architecture, which would show how much of this is product and how much is pattern.