Five years ago the classic incident postmortem opened with an unrotated credential. The 2026 version opens with an agent: a model wired to production systems through a chain of tools, servers, and credentials that nobody audited as a whole, because each piece looked like glue code rather than infrastructure.
We build production AI implementations and wire agents to real credentials for real clients, so we read vendor security bulletins in this space the way an operator reads weather. One from this month deserves attention, not because it is scandalous but because it is ordinary. AWS disclosed a server-side request forgery in its HealthLake MCP server: the server did not validate that pagination URLs pointed back to the expected endpoint, so a crafted token could redirect requests and send temporary credentials to an arbitrary server. Responsibly reported, promptly patched, fixed in a version bump. The vendor did its job.
The reason to study it is the class of bug it is. Nothing about it is exotic. It is unvalidated egress, one of the oldest server-side mistakes there is, showing up in a brand-new category of software: the plumbing between a model and your systems.
These are not AI vulnerabilities
Strip away the vocabulary and the recent crop of agent-security findings reads like a checklist from 2015. Requests that follow attacker-influenced URLs. Secrets flowing into logs that half the company can read. Tools granted wide credentials because scoping was left for later. Configuration loaded from directories nobody vetted.
Nobody invented new mistakes. What happened is that agent plumbing gets built fast, by teams under demo pressure, and treated as glue code. Glue code does not get threat-modeled. But an MCP server holding temporary credentials is not glue. It is privileged infrastructure with a network position most services never get: it talks to the model, to your data stores, and to the internet, often in the same process. The industry has not yet re-labeled it in its collective head, and the bug reports are what that lag looks like.
The audit, before the agent goes live
Here is the review we run before an agent touches production credentials. None of it is novel. Most of it gets skipped.
Scope the credential as if an adversary already holds it. The bulletin above carries a workaround worth reading twice: scope the IAM policy to least privilege rather than a wildcard resource. Assume the agent's credential will leak someday, and size the damage now. If the answer to "what could this token do in the wrong hands" is "anything," the design review is over and the redesign has started.
Treat tool flags as conveniences, not boundaries. The same bulletin is unusually explicit that a read-only flag is an in-process guard over the tool's own functions, not an IAM control: leaked credentials retain their full granted authority regardless of what the tool promised. This generalizes. Any safety property that lives inside the tool's process, a flag, a prompt instruction, an allowlist in application code, evaporates the moment credentials leave that process. Real boundaries live in IAM, in network policy, and in the data store's own permission model.
Validate every URL the plumbing follows. Pagination tokens, webhook targets, redirects, fetch-this-resource tools: each one is an egress path an attacker can aim. The fix is boring allowlisting of destinations, applied everywhere the agent's infrastructure makes an outbound request it did not originate. Boring is the point. The HealthLake bug existed because a URL from the response stream was trusted by default.
Keep secrets out of the transcript. Agent systems log prompts, tool calls, and responses by default, and those transcripts flow to observability platforms with broad read access. Anything the model can read, the log can leak, and the log's audience is always larger than the agent's. Redact at the boundary, and review the log store's permissions with the same seriousness as the database's.
Rehearse the rotation before you need it. When a credential does leak, the response is the same as it ever was: rotate in dependency order without taking production down (we wrote up what those first 24 hours look like). An agent estate adds one requirement: you have to know which tools hold which credentials, which means the inventory has to exist before the incident, not get assembled during it.
Why the plumbing keeps failing this way
The pattern under the pattern is velocity. Agent capability is moving monthly, and the connective tissue is being written at the speed of the demo cycle. Every era of fast infrastructure adoption has produced this same shape of incident, from the early years of cloud storage buckets to the early years of container orchestration. The systems were new. The mistakes were not.
That is the encouraging part. Securing agent plumbing does not require new science. It requires applying security engineering the industry already owns to a component class that has not yet earned the label "infrastructure" in most organizations. The teams that re-label it early, and put their MCP servers and tool gateways through the same review a public API endpoint would get, will skip most of this incident class entirely.
Before your first agent gets production access, or after it already has and nobody has looked closely, run the audit above with your own systems in the room. If you would rather run it with someone who has done it before, our implementation work includes exactly this review. AI that ships, not AI that demos.