Five years ago the typical incident postmortem opened with an unrotated credential. The 2026 version opens with an AI agent: a model wired to production through a chain of tools, servers, and credentials that nobody reviewed as a whole, because each piece looked like glue code.
Before an AI agent gets production credentials, audit five things: how far its credential reaches, where its real boundaries live, which URLs its tools follow, what its logs record, and how fast you can rotate its keys. None of these is a new AI problem. Each one is an old server-side mistake in a new place. We connect agents to real credentials in our client work, and this is the review we run first.
What went wrong in the AWS HealthLake MCP server?
On July 14, 2026, AWS published a security bulletin for its HealthLake MCP server (CVE-2026-15643). The server did not check that pagination URLs pointed back to the expected HealthLake endpoint. A crafted token could therefore redirect requests and send AWS credentials to another server. A researcher reported it through coordinated disclosure, and version 0.0.14 fixed it. The vendor did its job.
An MCP server is the connector that exposes one of your systems to an AI model through the Model Context Protocol, an open standard for connecting AI applications to tools and data. The bug class matters more than the bug. It is unvalidated egress, one of the oldest server-side mistakes, in a new category of software.
These are not AI vulnerabilities
Most AI agent security failures are ordinary infrastructure mistakes, not new classes of attack. Strip away the vocabulary and the recent findings read like a checklist from 2015. Requests follow attacker-influenced URLs. Secrets flow into logs that half the company can read. Tools get wide credentials because scoping was left for later.
Agent plumbing gets built fast, by teams under demo pressure, and gets treated as glue code. Glue code does not get threat-modeled. An MCP server that holds credentials 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 audit to run before an agent gets production credentials
Run these five checks before an agent receives any production credential. None of them is novel. Most of them get skipped.
Scope the credential as if an attacker already holds it. The AWS bulletin's workaround says it plainly: scope the IAM policy to least privilege rather than a wildcard resource. Assume the agent's credential leaks someday, and size the damage now. If the answer to "what could this token do in the wrong hands" is "anything," stop the review and start the redesign.
Put the boundaries outside the tool. The same bulletin says the server's read-only flag is an in-process guard only, not an IAM-level boundary. A leaked credential keeps whatever authority IAM granted it. Any safety property inside the tool's process (a flag, a prompt instruction, an allowlist in application code) disappears once the credential leaves that process. Real boundaries live in IAM, network policy, and the data store's own permissions.
Allowlist every URL the plumbing follows. Pagination tokens, webhook targets, redirects, and fetch tools are all egress paths an attacker can aim. Allow only known destinations. The protocol's own MCP security best practices give the same advice for request forgery: validate redirect targets and route outbound requests through an egress proxy. Boring is the point.
Keep secrets out of the transcript. Agent systems usually log prompts, tool calls, and responses. Those transcripts land in observability platforms with broad read access. Anything the model can read, the log can leak, and the log always has a larger audience than the agent. Redact at the boundary, and review the log store's permissions as seriously as the database's.
Rehearse rotation before you need it. When a credential leaks, the response has not changed: rotate in dependency order without taking production down. We wrote up what to do in the first 24 hours after API keys leak. Agents add one requirement. You must know which tools hold which credentials, and that inventory has to exist before the incident.
Why does agent plumbing keep failing this way?
Speed is the root cause. Agent capability changes monthly, and the connecting code gets written at the pace of the demo cycle. Every wave of fast infrastructure adoption produced the same shape of incident, from early cloud storage buckets to early container orchestration. The systems were new. The mistakes were not.
The encouraging part: securing agent plumbing needs no new science, only the security engineering the industry already owns, applied to a component most organizations have not yet labeled infrastructure. Teams that give their MCP servers and tool gateways the review a public API endpoint gets will skip most of this incident class. Credentials are one layer; for the environment layer, see how a small team can contain AI agents.
Before your first agent gets production access, or after it already has, run this audit with your own systems in the room. If you want someone who has run it before, our AI implementation framework includes this review. AI that ships, not AI that demos.