Every AI agent that connects to a business system carries implicit trust. Good agents are capable of reading team emails, keeping records up to date in CRMs, messaging colleagues, and triggering financial workflows all on a user’s behalf. The access to perform real business tasks is what makes agents useful. It’s also what makes the systems that broker that trust an attractive target for bad actors.
While the first generation of agentic AI deployments was defined by what agents could do, the next is set to be measured by whether enterprises can trust them to do it safely. That’s why six months ago Arcade.dev proactively addressed new variants of the COAT (Cross-app OAuth Account Takeover) vulnerability: an identity attack targeting OAuth-as-a-Service systems. When addressing this threat surface, we said then that the industry needed to take these types of risks seriously.
Fast forward to today, and the same research team has published a follow-up paper introducing a new attack class and outlining countermeasures that hold up against it. It’s a clear reminder that in agentic AI security, vigilance is an ongoing discipline, not a one-time fix. To understand why these systems attract sophisticated attackers and what it takes to build defenses against them, it’s helpful to start with what makes them such enticing targets in the first place.
What Makes Agentic Infrastructure a High-Value Target
Agent runtimes are credential aggregators by design. When an enterprise deploys agents across its corporate systems, a single integration system ends up holding OAuth tokens for GitHub, Gmail, Slack, Salesforce, and so on simultaneously across thousands of users. That consolidation is what makes a breach at the system layer so consequential. An attacker who compromises the system doesn’t need to work their way through each downstream system one by one. They’re already inside all of them.
Research presented at IEEE S&P 2026, one of the most prestigious security conferences in the world, formally documents three attack classes that exploit how OAuth connections are managed in connector ecosystems:
Cross-user OAuth Session Fixation (COSF) is the newest of the three. An attacker initiates an OAuth flow from their own account and then sends the resulting authorization link to a victim. When the victim clicks the link, they unknowingly complete an OAuth flow initiated by someone else, silently linking their connector access to the attacker’s account. No credentials are stolen in the traditional sense. The victim simply completes what appears to be a routine authorization, and the attacker walks away with access to their resources.
Cross-tenant COAT broadens the original COAT attack beyond a single tenant. Because many OAuth-as-a-Service systems adopt a shared redirect URI across all tenants and connectors, a malicious agent operating in one can intercept auth codes intended for a legitimate connector in a completely separate tenant. This even applies to ones with a closed, invite-only ecosystem. The root cause is a failure to verify that the connector completing an OAuth flow is the same one that initiated it, and that both belong to the same tenant.
Cross-tenant Client ID Confusion breaks tenant-level scoping in OAuth flows, allowing authorization context to bleed across organizational boundaries in ways the system never intended.
Together, these attack classes illustrate what the researchers call the “trust inheritance” problem. Once a system has established OAuth relationships with an enterprise’s systems, that trust can be weaponized if any layer of the system is compromised. And the exposure isn’t limited to the OAuth layer. Internal agentic tooling introduces attack vectors that traditional security mechanisms were never designed to account for. This includes the monitoring systems, automated remediation pipelines, and sandboxed execution environments that systems deploy to run their own infrastructure. A poorly isolated internal tool with broad privileges is an attacker’s best friend.
In a threat landscape that’s still taking shape, the only durable defense is a security architecture and philosophy grounded in continuous vigilance as the surface evolves.
Arcade’s Security Philosophy: Proactive Vigilance
In April 2025, the researchers behind the COAT findings approached Arcade with their new work. Their disclosure gave us an early look at vulnerabilities that most of the industry hadn’t yet encountered. We knew our architecture needed to adapt to properly mitigate this entire class of security issues.
The remedy wasn’t straightforward. Addressing the vulnerabilities presented by COAT required redesigning Arcade’s authorization flow, introducing mandatory user verification at the point of authorization. Two principles guided every decision along the way: keep Arcade easy to use, and remain secure by default.
What we landed on was binding authorization flows to verified user sessions. When a user initiates an OAuth connection, the system now verifies that the user completing the flow is the same user who started it. The attack vectors that COAT and COSF depend on are closed at the root level: the ability to hand off an initiated flow to an unsuspecting victim no longer has a path through.
That approach has since been independently validated. The research team’s latest paper, “Demystifying the (In)Security of OAuth-based Account Linking in Connector Ecosystems,” cites Arcade, alongside Amazon and Microsoft, as vendors that have adopted appropriate countermeasures for these attack classes. That recognition matters less as a point of pride and more as a confirmation that these architectural decisions are critical to the future of secure enterprise agents.
The same researchers are now leading standardization efforts at the Internet Engineering Task Force (IETF), the body responsible for the protocols that underpin the modern internet, to encode these countermeasures as formal updates to OAuth security best practices. The goal is to raise the floor for the entire industry, not just the companies paying attention today.
Arcade will keep engaging with that community, publishing what we learn, and building to whatever the standard demands next.
The Architecture Decisions That Determine Security Posture
Security outcomes are determined by the architectural decisions made long before any attacker shows up. A system built with a minimal attack surface and strong isolation properties is fundamentally harder to compromise than one where security is layered on after the fact. Here’s how Arcade has identified what secure enterprise agents look like in practice.
Minimal surface area by design
Some integration systems pass raw API responses directly to agents: every field, every attribute, every piece of metadata the API returns, whether the agent needs it or not. Arcade agents receive only the specific fields required to complete a task. That design choice is both a performance optimization and a security posture. The less data flowing through an agent’s context at any given moment, the smaller the blast radius if that context is ever compromised.
Credential isolation and custody
How a system stores and manages OAuth tokens is one of the most consequential architectural decisions teams can make. Arcade stores OAuth tokens and user secrets only after they have been encrypted at the application layer. Even a backup contains only ciphertext for this sensitive data. Additionally, Arcade uses per-operation randomness for salting, so even if two secrets have the same plaintext value, they will be encrypted differently. Access control is enforced at the data layer, not just the application layer. Every token read and write requires a verified match across tenant, project, and account verifiers.
In Arcade Cloud, keys are Arcade-managed. Enterprises needing key custody can do so by self-hosting or through hybrid deployment, where rotation is fully supported by Arcade’s tooling.
Limiting the blast radius of internal systems
The same principles that apply to customer-facing architecture apply to a system’s own internal tooling. Agentic monitoring systems, automated remediation pipelines, and sandboxed execution environments all call for careful privilege separation. An internal tool that is able to read production credentials and also accept inbound connections from the internet is a liability, regardless of how well the customer-facing product is locked down.
For enterprises evaluating agentic runtimes, the right due diligence today goes beyond just the feature list. Vendors should be able to speak clearly about how tokens are stored and encrypted, who within their organization can access them, how internal tooling is isolated from production systems, and what their vulnerability disclosure process looks like. Those answers reveal whether security is built into the architecture from the start.
The Bigger Picture: Agentic Industry Standards Are Still Being Written
The enterprises deploying agents at scale today are doing something more consequential than running software. They’re establishing what production-grade agentic AI looks like, and by extension, what the security bar for the entire industry will be.
In January, we wrote that not all integration systems had mitigated COAT, and that we hoped they would follow suit in establishing new best practices for security. That’s even more pressing now. The attack surface has expanded, a new class of vulnerabilities has been identified, and the research community is actively working to translate those findings into industry standards. The IETF standardization effort underway means that the countermeasures Arcade implemented are on a path to becoming the widely recognized baseline for the entire industry.
That process only works if the wider community is engaged. Security researchers need vendors who take disclosures seriously. Enterprises need vendors who don’t wait for a breach to act. And the industry as a whole needs runtimes willing to make difficult architectural decisions, even when it means significant engineering investment, because the alternative is a race to the bottom on security that no one wins.
Arcade is committed to being part of that work. We’ll continue engaging with the research community, publishing what we learn, and building to whatever the standard demands next. The standard is still being written, and we intend to help write it.
Arcade is built for enterprises deploying real agents to production. Security shapes every architectural decision we make, because the enterprises that get this right today are the ones setting the industry standard. Read more about how we’re leading agentic security here.
