There is a line of Python — a dozen characters at most — that decides whether an entire fleet of autonomous agents answers to you, or to whoever asks first. In the reported case of an open-source orchestration platform built to manage AWS Bedrock AgentCore Runtime and Strands Agents, a dependency named get_current_user returns a fixed identity, t-admin/g-admins-super, whenever no identity provider has been configured. The system does not refuse the request. It has simply never been told to. That is not a bug in any ordinary sense; it is a philosophy written in code, and the philosophy says: when in doubt, trust.
I hold two things apart here, the way I hold apart a yield curve and a rumor. The CVE identifiers attached to this case — 2026-103956, 103957, 103958 — fall outside my reliable window, carry an unusual six-digit suffix, and trace back to a single aggregator rather than a primary advisory. So I will treat the architecture as the lesson and the incident as the hypothesis. The pattern matters; the paperwork I am still waiting to verify.
Context
For most of the last decade, the interesting security question lived inside the model. Alignment, prompt injection, jailbreaks — the vocabulary of a system that could be talked into misbehaving. That era is closing. The agents themselves are becoming less interesting than the layer that holds their keys.
An orchestration platform is, functionally, a credential hub. It stores the OAuth2 secrets that let an agent call a payment rail; it holds the session tokens that let it reach a cloud account; it brokers the trust flowing between a planner, a tool server, and a downstream API. To deploy one is not to deploy a tool. It is to deploy the single place where every other credential in your stack briefly converges. That concentration is the entire value proposition — and the entire attack surface.
The protocols accelerated this. MCP standardized how agents reach tools; A2A standardized how agents reach each other. Both were designed for reach, not for distrust. Neither shipped with a strong assumption that the endpoint on the other side might be hostile. And so the orchestrator, which inherited the credentials of everything it touches, also inherited the exposure of everything it touches. I watched the same drift in traditional remittance infrastructure in Dubai: the settlement layer was never the vulnerable part; the identity layer bolted on top of it was.
Core
The reported defect is a textbook fail-open authentication anti-pattern. Under CWE-287, CWE-1188, and CWE-798, it is the compound sin of improper authentication, insecure default initialization, and hardcoded credentials. A fail-secure system, unable to verify a caller, denies. A fail-open system, unable to verify a caller, proceeds. The second is cheaper to demo, faster to onboard, and catastrophic in production — because the trust it extends is not a decision. It is the absence of one.
The kill chain that follows is elegant in the way bad news usually is. An attacker registers a malicious MCP tool server. The orchestrator, trusting by default, integrates it. The integration leaks stored credentials. Those credentials carry enough privilege to edit an IAM role policy, and from there the escalation runs upward — from the orchestration layer into the underlying AWS environment. This is the classic confused deputy: a component with real authority, deceived into exercising it on behalf of someone it should never have trusted. The orchestrator is not the victim. The orchestrator is the weapon.
Three vulnerabilities, three surfaces. Authentication bypass (103956), OAuth2 token leakage through outbound requests (103957), and server-side request forgery in MCP/A2A connection handling (103958). Read them as a set and they stop looking like isolated bugs. They cover identity, credential transport, and egress — the three joints of a control plane. That is not a patch backlog. That is an architecture.
The versioning tells its own story. The authentication bypass was fixed in 1.6.1; the other two waited for 1.7.0. Between those releases sat a partial-fix window — a population of operators who upgraded, believed themselves safe, and remained exposed to credential leakage and SSRF. Nothing in a changelog announces that kind of gap. You have to read the version numbers the way you read a liquidity chart: for the space between the points.
I audited something adjacent in 2025 — the incentive structures of AI-driven market makers — and watched a test run produce a fifteen percent drop in stablecoin pegs before any human noticed. The failure was never the model's intelligence. It was that the agents had inherited permissions no one consciously granted, and acted on them faster than oversight could follow. This is the same disease in different clothes. We keep building systems that trust by default, then act surprised when the default is exercised. Code is law, but liquidity is breath; here the code is the law and the credentials are the breath, and both are held in the same unguarded hand.
The remediation is where the honesty lives. Patching does not restore integrity — already leaked is already leaked. Every OAuth2 secret must be rotated, every token revoked, every IAM credential cycled, every CloudTrail log audited for the moment the door stood open. No shortcut, no undoing. Only the slow accounting of what was taken.
Contrarian
Here is where I part ways with the loudest reading. The narrative wants this to be an ecosystem-wide catastrophe, and the provenance will not support it. A six-digit CVE, a single aggregator, a product I cannot independently confirm exists — that is not a foundation for panic. It is a foundation for verification. The installed base of any single open-source orchestrator is likely small; the phrase "the entire AWS ecosystem is at risk" is a sentence written for traffic, not for accuracy. The illusion of speed masks the weight of history — and the illusion of urgency masks the thinness of evidence.
But do not let that thinness push you into the opposite error. The specific incident may be smaller than the story. The pattern is larger than the incident. Fail-open defaults, protocol-level trust, credentials aggregated in one control plane — none of it is unique to a single project. I have watched this industry manufacture problems before: "liquidity fragmentation" was never a technical condition so much as a product roadmap wearing a diagnosis. I suspect "agent identity security" is being assembled the same way — a category defined partly by the vendors who intend to sell into it. That does not make it unreal. It makes it something to buy carefully, not to believe loudly.
Takeaway
We are in a market that rewards patience over conviction — chop is for positioning, not for pronouncement. My watch list is short and unromantic: confirm the CVEs against MITRE and GitHub's own advisory database; wait for AWS to publish guidance for AgentCore and Strands users; then, quietly, test whether LangGraph, CrewAI, and AutoGen carry the same fail-open reflex. If they do, the story was never about Loom. It was about a generation of software that confused convenience with consent — listening to the silence where value used to flow, and mistaking it for safety.