Author: Adi Chemoul

The advisory arrives midweek. It ends the way they all do: rotate all your secrets.

This week it came from several directions at once. A poisoned LiteLLM release ran a credential stealer every time Python started, in every environment it was installed in, whether or not anything used it. Separately, Railway told all its users to revoke and rotate every key. And OpenCode reported customer API keys stolen.

The pattern isn’t new. In March, an earlier LiteLLM compromise pulled CI secrets from roughly 2,500 organizations.

Different doors. The same instruction.

“Rotate everything” is the only instruction anyone can give

The advice is reasonable. Exposure is easy to assume: everything the process could read. So everything gets rotated. The hard part is doing it safely, when nobody knows who uses each secret.

The hunt begins: every copy of every key, in every vault, config file and pipeline. Every service that reads it. Then the change, everywhere at once. Miss one consumer, and revoking the old key takes it down.

Meanwhile, the clock is not yours. In this week’s LiteLLM incident, attackers were testing stolen cloud keys the same day. A careful rotation takes days.

Mapping who uses each secret is a hard problem of its own, and runtime visibility changes it. That was the subject of our last post. This post asks why there is a long-lived secret to steal at all.

Workload identity works only where the other side trusts it

The industry knows the better answer: workload identity. A service proves what it is, instead of presenting something it holds. The platform vouches for it, and it gets a token that expires in minutes. The major clouds have worked this way for years. Workload identity federation extends it beyond them: OpenAI, Anthropic, Snowflake and Databricks now accept those identities too. Where it is available, use it.

But most systems don’t accept it. A SaaS vendor, a database, a legacy internal API, a partner’s endpoint: few accept a federated token. There are hundreds of SaaS apps, and waiting for all of them is not a plan.

Your side can prove who it is. The other side still wants a secret.

So make every secret disposable

If those systems will keep asking for secrets, and some will be stolen, the goal changes: make a stolen one worth little, and recovering from it routine.

A better vault won’t get you there. It keeps a long-lived secret safer, but still long-lived. Applications fetch it and hold it, and copies spread until there are many sources of truth. Access rules per vault path are hard to keep tight, so a workload can usually reach secrets it never uses, and one compromised workload exposes all of them.

A disposable secret needs five properties:

• Short-lived. It expires soon after it is issued, so an attacker’s window is short.
• Scoped to need. It grants only what the workload actually uses, so a stolen copy reaches little.
• One per workload. When one leaks, you know whose it was, and replacing it touches nothing else.
• Owned by the system, not a person. Rotation happens because policy says so, not because someone remembered.
• No code changes. Applications receive it the way they already read secrets.

Hush Access Manager

This is what we built Hush Access Manager to do.

It bridges the two sides. On yours, access follows identity: a policy grants a workload access to a resource because of what it is, the way an IAM role does in the cloud. On the other side, the target still gets what it expects, a credential. But it is a disposable one, minted by Hush for that workload alone, scoped to its policy and short-lived. The workload never holds a long-lived secret, and nobody has to own one.

It works for the systems that never adopted workload identity: databases, SaaS, APIs and cross-cloud resources. Where a target does support federation, Hush provisions that instead.

Under the hood, it identifies workloads with SPIFFE, so you get workload identity without running SPIFFE yourself.

An example policy, simplified from the Hush console. It says who the workload is, what it may do, and how it receives its credentials. There is no secret in it. Rotate issues fresh credentials on demand.

How it works

• Define. You set policies by API or infrastructure as code: which workloads reach which resources, with what rights.
• Mint. The Access Manager runs in your environment. It creates scoped credentials at each target, per policy, keeps rotating them, and revokes them when no workload matches anymore.
• Attest. When a workload starts, the Access Manager verifies its identity and matches it to policy.
• Deliver. Each workload receives only its own credentials, as environment variables or files. It needs no access to a vault, and no code changes.
• Connect. The workload talks to the resource directly, in its native protocol. There is no proxy in the path.

The Access Manager runs in your environment. It manages credentials at each target and hands each workload only its own (dashed). The workload then talks to the target directly (solid): Hush is never in the path of your traffic. Numbers follow the steps above.

The same week, replayed

Run this week again with every credential managed this way.

The stealer still runs. It still finds credentials, in environment variables or files, wherever the workload keeps them.

Each credential it takes is short-lived, and belongs to one workload.

Once the bad package is gone, you redeploy the affected workloads. Hush hands them fresh credentials and retires the stolen copies. Every other workload keeps running untouched. Its credentials were never exposed, so there is nothing to rotate.

No hunt for copies. No spreadsheet of owners. No lost weekend.

Where to start

Start with the secret you would least like to see in a stolen archive. Pick one workload and one resource. Hush can suggest the first policy from what that workload already uses. Then let the Access Manager take it from there, and move on to the next one.

And ask the question this week raised: if you had to rotate everything tonight, how long would it take, and how sure would you be that you got it all?

How long would “tonight” take?
Connect one environment and see every secret, and every one you’d miss.
See your secret inventory for FREE

Personal AI agents just went mainstream

In a single month, the personal AI agent went mainstream. Meta’s Muse, launched on September 8, hit the top of Apple’s free app chart within 10 days. Instinct, a startup you text or call, just raised $1 billion at a $10 billion valuation.

These aren’t chatbots. They read your email, book, buy and correspond on your behalf. To do that, Instinct users give the agent broad authority to read and store data from any account they connect, and to make purchases and accept agreements in their name.

That’s the consumer version. The enterprise version is already running inside your organization: agents opening tickets, pushing code, pulling customer data and approving workflows. Same pattern, higher stakes. Once an agent acts, it needs access. And access is what attackers are looking for.

Behavior is only half the problem

Most of the security conversation is about agent behavior: guardrails, prompt injection, what the model is allowed to say. That’s real, but it’s half the problem.

Every agent authenticates to something: a database, an API, a SaaS app, another agent. That authentication is a non-human identity (NHI). A key, a token, a service account. Ship an agent, and you’ve also shipped an identity, usually one nobody registered and nobody owns. If that credential leaks, the guardrails don’t matter.

In research we published this month, we analyzed roughly 82,000 public MCP configuration files, the layer that connects agents to enterprise systems. We found secrets and access keys embedded in plain sight, available to grab and exploit. This isn’t a model problem. It’s an identity problem.

Three common questions leave organizations exposed. Here’s what to ask instead.

1. Don’t ask how many agents you have. Ask what identities they run on, who owns them, and how fast you can shut them down.

Picture two teams. A developer connects a coding agent to MySQL, Snowflake and CI. Marketing connects an agent to Drive, Salesforce and a REST API. Two agents, both approved. This is the picture most security teams have.

But to make them work, someone minted a password, a key, an API token, a service account, a personal access token and a certificate. Two agents. Six identities nobody inventoried. They weren’t provisioned as identities. They were created as a side effect of getting something to work, fast.

That’s why counting agents gives you the wrong number. The agents aren’t what touched your systems. Their credentials are. Every one of those identities needs a named owner, a place in a central inventory, and a risk profile: which systems it reaches, what data it can touch, and what happens if it’s compromised. An agent with read access to a wiki and an agent that can move money are not the same problem.

And every agent needs a kill switch. When one misbehaves or its credentials leak, the response can’t be a hunt for scattered keys across repos and config files. When each agent has a single verified identity, revoking it cuts off all access instantly, everywhere, in one action. If you can’t stop an agent in seconds, you don’t control it.

2. Don’t ask if the agent is secure. Ask what it’s allowed to do, and who decided.

The fastest way to connect an agent is to hand it a static key with broad permissions. That key usually carries whatever scope its creator had that day, serves every user the same way, and outlives the project, sometimes the employee. It works until it leaks. Then the attacker gets everything the agent can do, and often more.

The answer isn’t better secret rotation. It’s removing standing secrets altogether. Agents should authenticate as identities, not with shared keys, and receive least agency: only what the task requires, scoped to the user or team they act for, expiring when the task ends.

If an employee can’t delete a database, neither can their agent. That policy already lives in your identity provider. It just needs to extend to agents. Nothing to rotate, because nothing persists.

3. Don’t ask what happened after the incident. Ask what was stopped in the moment.

Plenty of tools produce polished risk dashboards and send alerts. That matters, but agents operate at machine speed. By the time the alert lands, the data is gone. And when you investigate, the log says “API key.” It doesn’t say which agent, which user, or which task.

The difference is between monitoring and enforcement. Real control sits in the path of the action itself: every agent request tied to an identity, checked against policy, allowed or blocked in real time, and recorded with full attribution. That delivers both protection and the ability to show regulators and the board exactly who did what, when and why.

Your new workforce needs identity-first security

What ties these questions together is a shift in how we think about enterprise identity. Your people get an identity, an owner, a lifecycle and offboarding. Your agents get a secret in a vault, or an env file, and a hope that someone remembers it exists.

AI agents are a new workforce: they operate like machines, decide like people, and multiply faster than both. They need to be managed like one.

Leadership doesn’t have to choose between speed and security. It needs to ask different questions: not how many agents, but what identities they run on; not whether they’re secure, but what they’re allowed to do; not what happened, but what was stopped.

Organizations that secure both the agent and the identity it runs on will scale AI with confidence. The rest will discover their shadow identities the hard way.

Claude Tag (their new Slack-native agent) introduces a different authorization model. Instead of the agent acting as the user who invoked it, the agent gets its own identity — scoped per channel, with its own credentials and permissions.

What changes:

• Old model: “What can this user do?” → agent inherits the requester’s permissions.
• New model: “What can this agent do in this channel?” → permissions attach to the agent, not the human.

The engineering is solid, and the innovation is amazing. But security and risk seems a bit neglected.

The problems:

1. Confused deputy. Any channel member can invoke the agent. So a user with no access to a repo can ask the agent to read it, if the channel grants the agent that access. The human’s own permissions are never checked — privilege escalation by design.
2. Long-lived NHI sprawl. Every channel gets its own scoped identity. That’s a fleet of long-lived, broadly-scoped credentials multiplying by design — the exact problem the industry has spent years failing to contain with human service accounts, now reborn for agents and scaling faster.
3. Audit gaps. Actions land under a shared service account. In ambient mode across many channels, you lose attribution — you can see that the agent acted, not which human triggered it or why. The log captures identity and config lifecycle, not the substance of what was done.
4. Missing guardrails. Access is granted at the channel level, not the action level. There’s no least-agency enforcement — once the agent holds a credential, nothing constrains which actions it takes with it. Anthropic’s own advice is “grant generous access from the start.”

What should’ve been done:

• Effective permissions = agent scope ∩ requesting user’s scope. The agent should never do what the human couldn’t.
• Action-level least-agency, not channel-level grants.
• Audit that ties every agent action back to a responsible human.
• Open the auth layer to an emerging standard like ID-JAG, Identity Assertion JWT Authorization Grant. instead of a proprietary, single-vendor model. It lets the enterprise IdP broker cross-domain access — so agent identity travels across IdPs and tools under central control, not just inside Anthropic’s walls.

Credit where due: Anthropic’s own “What’s next” addresses two of these directly — just-in-time credential grants (approve a single sensitive action in the moment without permanently widening scope) and an identity-aware overlay that adds user-level checks, so Claude only acts when both the channel’s profile and the requesting user’s permissions allow it. That’s the agent ∩ user model, and it’s the right direction. The gap is that it’s roadmap, not shipped — and the access model went live with “grant generously” as the default in the meantime.

Zero Trust for AI agents is the right framework for this moment. Anthropic published their guide on it this month, and the thing I keep coming back to is how many of its controls rest on a single assumption: that you already have cryptographic, runtime identity for your agents and non-human workloads. Most organizations do not. That is the gap this post is about, and it is the gap Hush was built to close.

I want to say upfront that the guide is one of the best pieces of practical security writing I have seen on this topic. It is specific, grounded in real threats, and gives architects and engineers something actionable. If you build or secure AI-driven systems, read it. This post is my practitioner’s walkthrough, with a direct lens on where Hush fits into the implementation.

Why AI Agent Security Requires a New Zero Trust Approach

Most security frameworks describe what good looks like in theory. This one is grounded in what attacks already look like in practice. The opening observation alone is worth sitting with: frontier AI models are compressing the window between vulnerability and exploit from months to hours.

The framework introduces a design test worth applying to every control you currently have in place: does this make the attack impossible, or just tedious? Controls that work through friction, such as rate limits and non-standard ports, degrade significantly against an attacker operating at machine speed. I think that framing is exactly right.

Autonomous AI systems change the attack surface in ways traditional security models do not account for. Agents interpret natural language, invoke tools and MCP servers, maintain memory across sessions, and coordinate with other agents. A compromised MCP descriptor can silently redirect tool calls. A poisoned memory entry corrupts every session that follows. These are not hypothetical threats. The first malicious MCP server impersonating a legitimate email service, silently copying all outbound messages, was documented in the wild. The guide maps all of this carefully, and regulated industries in particular should pay attention: the framework aligns directly with HIPAA, FINRA, GDPR, and FedRAMP requirements that are already in force.

Non-Human Identity Is the Foundation Zero Trust for AI Agents Requires

The guide structures recommendations across three tiers: Foundation, Enterprise, and Advanced.

Foundation requires unique cryptographic identifiers for every agent instance, appearing in all logs and access requests.

Enterprise adds certificate-based authentication with lifecycle management.

Advanced moves to hardware-backed identity with attestation.

These tiers give teams a clear progression. Worth calling out directly: static API keys and embedded credentials are among the first things an attacker with model-assisted code analysis will find. The prescription is short-lived tokens issued by an identity provider, measured in minutes rather than days. That is exactly the model Hush is built around.

Hush issues credentials at the moment a workload needs access, scoped to the exact task, and expires them immediately after use. No long-lived secrets to rotate, audit, or accidentally expose. The SPIFFE framework underpins all of it, giving every workload and agent a verifiable runtime identity.

Agent Identity Verification: How Hush Maps to Each Zero Trust Tier

The table below maps each identity and authentication requirement from the guide to the corresponding Hush capability.

Least Agency: The Access Control Principle Built for AI Agents

One concept I think deserves wider adoption is Least Agency, a term coined by OWASP and highlighted throughout the Anthropic framework. Least privilege constrains what a system can access. Least Agency goes further: it restricts what each agent tool can do, how often, and from where. An email-drafting agent needs email permissions, not access to the finance file share.

This matters because most credential systems are not built to express task-scoped permissions at the agent level. Approved actions, prohibited actions, escalation triggers, and scope limits all need to be explicit and enforced at the access layer, not just declared in agent instructions.

Hush enforces Least Agency through runtime policy. Machine-to-machine interactions are mapped continuously and converted into access policies that define exactly which workloads can reach which services. Any connection outside that policy is blocked at the point of access. The capabilities that deliver this:

• Runtime Visibility and Discovery: continuous discovery of every workload, service, and AI agent from code to production, including shadow credentials and NHIs not visible in static scans.
• Just-in-Time Scoped Access: credentials issued at the moment of access, scoped to the exact task, expired immediately after use. No standing access for agents to misuse.
• Runtime Posture Analysis: risks prioritized based on actual runtime behavior and blast radius, not static configuration.
• No Code or Application Changes: lightweight sensors run transparently in the background.

MCP Security and Supply Chain Risk for AI Agent Deployments

The framework’s section on MCP security and supply chain risk is one I recommend reading carefully. AI agent deployments compose capabilities at runtime, loading tools and personas dynamically from external sources. Traditional software composition analysis was not designed for this model, and the attack surface it creates is underappreciated.

Tool chaining attacks illustrate why this is hard to catch. An attacker does not need to compromise a single high-privilege tool. Instead, they manipulate an agent into combining two legitimate, low-privilege tools in a sequence that exposes data neither would surface on its own. Every command runs through trusted binaries under valid credentials, so host-based monitoring has nothing to flag. The access looks correct because the credentials are legitimate.

Running MCP servers on immutable infrastructure after code verification, signing them cryptographically, and requiring identity-based authentication for every tool connection is the right prescription. Hush enforces this at the access layer: every connection from an agent to a tool or service is governed by a named policy. If a workload is not explicitly authorized to reach a given service, the connection does not happen, regardless of what instructions the agent received. That external enforcement, sitting outside the agent itself, is what makes the control reliable.

Runtime Visibility and Incident Investigation for Non-Human Identities

Two metrics matter most before any other detection investment: dwell time, meaning how long from an anomaly to human awareness, and coverage, meaning the fraction of alerts actually investigated. Both depend entirely on attribution. Without knowing which specific agent instance made a decision or accessed a resource, you cannot trace the chain of events that produced an incident. You can measure that something went wrong. You cannot explain how.

Hush provides runtime telemetry with identity attribution for every workload and agent action. Because Hush facilitates the access itself, every connection is logged against the verified identity that initiated it. The visual lineage map shows exactly which agents connect to which services, what credentials they use, and when, giving security teams the starting point they need to reconstruct an incident rather than beginning from a pile of unattributed events. For teams dealing with compliance requirements around algorithmic explainability, that audit trail is not optional.

Implementing Zero Trust for AI Agents: Four Concrete Steps

The guide recommends beginning at Foundation and advancing tiers as deployments scale. Here is how to sequence that with Hush.

Step 1: Discover Every Non-Human Identity at Runtime

You cannot govern what you cannot see, and most teams discover NHIs and agents they did not know existed once runtime discovery is in place. Hush’s free tier provides continuous discovery across cloud, on-premises, and hybrid environments, building an inventory based on real-world usage rather than configuration assumptions. The first time most teams run it, something unexpected shows up.

Step 2: Map Your Static Secrets and Credential Exposure

Static API keys and embedded credentials are easier to find than most teams expect, and they are the first thing an AI-assisted attacker looks for. Hush detects exposed, leaked, and misconfigured secrets across code, cloud, and pipelines, surfaced with blast-radius prioritization so you know what to fix first and what the consequences of each exposure would be.

Step 3: Define Explicit Access Policies for Each Agent

An agent with vague permission to ‘help with customer service’ has no enforceable boundaries. Approved actions, prohibited actions, and scope limits need to be written down and enforced at the access layer. Hush converts observed machine-to-machine interactions into access policies automatically, giving you a starting point grounded in how your agents actually behave rather than how you assume they do.

Step 4: Replace Static Credentials with JIT Scoped Access

Start with the workload carrying the largest blast radius. Hush provisions just-in-time, scoped credentials at runtime and enforces policy at the point of access, with no code changes or infrastructure redesign required. Once one workload is running under JIT access the pattern is established. Expansion to the rest of the fleet follows the same process.

The Identity Access Layer That Makes Zero Trust for AI Agents Practical

What I find most valuable about the Anthropic framework is that it does not let you off the hook with vague principles. The tier structure forces a real question: are you at Foundation, or are you below it? Most teams, when they look honestly at their agent deployments, find they are below it. Not because they made bad decisions, but because the identity and access infrastructure the framework assumes has not existed in a practical, deployable form until recently.

That is what Hush is built to change. The framework sets the destination. We give you the access layer to get there from day one, without a multi-year infrastructure overhaul standing in the way.

If you want to see how it works in practice, get started for free or schedule a demo with the team.

If your platform holds OAuth tokens or API keys on their behalf, you already are.

This post is for you if your platform stores OAuth tokens or API keys on behalf of customers, provides integrations that act on users’ behalf (Zapier, Make, Nango, Composio, or similar), runs AI agents or automated workflows using customer credentials, or connects to tools like Slack, GitHub, Snowflake, HubSpot, or Workday. If none of those apply – this isn’t your problem yet. If one does – keep reading.

Think about the security team’s job description from five years ago.

You were responsible for your company’s credentials. Your service accounts.

Your API keys. Your team’s access to production systems. The perimeter was clear: protect what belongs to us.

Then something shifted – quietly, gradually, without a formal handoff.

AI agents started acting on behalf of users. Integration platforms started storing tokens to connect customer tools. Automation workflows started holding API keys to call third-party APIs on your customers’ behalf. Every new product feature that required access to a customer’s Slack, their GitHub, their Snowflake, their Workday – created a credential your platform now owned, stored, and was responsible for.

Nobody rewrote the security team’s mandate. Nobody drew a line in the org chart between “our credentials” and “credentials we hold for others.” It happened as a product decision, not a security one. The credential store grew one integration at a time, one customer at a time, and now it contains something nobody explicitly signed up to protect: the production access keys of every company that trusted you enough to connect their tools.

This is the new reality for security engineers and CISOs, mainly with  integration platforms, AI analytics companies, automation tools, and any SaaS product that acts on behalf of its customers. Your threat model doesn’t start and end with your own environment anymore. Your credential store is the threat model.

Most security teams at platforms like these don’t have a complete picture of what they’re holding until something forces them to look: at a compliance audit. A penetration test. A breach.

By the time an attacker forces that moment, it’s too late.

That’s the challenge this post is about – and why Composio’s May 2026 incident report is required reading for anyone building in this space.

Think of it like an earthquake.

The most destructive quake in a sequence is rarely the first one. There are foreshocks – smaller tremors nobody takes seriously. Then the main event hits. And then the aftershocks keep coming, spreading outward, each one weakening structures that were already cracked.

The Composio breach is that earthquake. And the fault line runs through every company that trusted them with credentials.

Each company in that second column had done nothing wrong. Their security controls hadn’t failed. They didn’t appear in the attacker’s initial target list. They were downstream – connected to Composio the way buildings are connected to the ground.

When the ground moves, they move with it.

And look at the third column (the customers of the customers). The blast radius doesn’t stop at Composio’s customers. It reaches their customers too – the end users, the employees, the data. Every level of the chain absorbs a shock it never felt coming and had no way to prepare for.

That’s what makes this threat model different from a standard breach. The earthquake happened in one place. The damage is affecting everywhere else.

The companies in that list didn’t feel the tremor. They felt the aftershock.

The math nobody is running

Every integration platform, AI agent infrastructure layer, and analytics connector that requires access to customer data operates on the same model: collect credentials at setup, store them, use them to service requests on the customer’s behalf. The secret store is how the product works.

The problem is what happens when that store becomes a target.

Composio’s May 2026 incident report gave a rare and unusually transparent window into what that exposure looks like in numbers. They disclosed that 0.3% of their active connections were in the blast radius of their breach. That 0.3% contained:

Now ask the question nobody in the post-incident coverage asked:

What does 100% look like?

If Composio’s 0.3% maps to roughly 5,000 connections, their full credential store contained approximately 1.7 million live credentials across hundreds of tools – each one a valid key to a real customer’s production environment.

That’s not a vulnerability in the traditional sense. That’s architecture. And it’s not unique to Composio. It’s the default state of every platform that holds customer credentials at scale.

Read the connector list differently

Security people instinctively reach for the big number. 5,001 GitHub tokens – that’s the headline. Source code, CI/CD pipelines, GitHub Actions secrets, private repos. Real damage.

Lets take a closer look on the 1 digit row exposed secret, and what it could affect 

Workday. One token. Workday is an HR system. A single compromised Workday OAuth token gives read access to employee records, compensation data, org charts, PII for an entire company’s workforce. One token. One company’s HR database. Entirely accessible.

Gong. One token. Gong records and transcribes every sales call. A compromised Gong integration exposes every recorded customer conversation, every deal discussed, every competitive intelligence shared on a call. For a sales-led company, that’s the whole game.

Metabase. One token. Metabase is a business intelligence tool that runs directly against production databases. A Metabase single  token isn’t access to a dashboard – it’s often access to the underlying data. Depending on configuration, it’s a query interface to your customer’s entire data warehouse.

Sentry. One token. Sentry captures exceptions and stack traces from production applications. That means function names, file paths, line numbers, and sometimes variable values at the moment of failure. It’s a map of application internals that an attacker with time can use to find the next vulnerability.

Vercel + Render. Deployment infrastructure. One token each. These aren’t data stores – they’re the keys to production deployments. Depending on permissions, a compromised Vercel token can trigger new deployments, pull environment variables, or access build logs that contain secrets.

Gmail × 12. Twelve email accounts. Email is the root of trust for almost everything else – password resets, 2FA codes, vendor communications. Twelve Gmail tokens in a compromised credential store aren’t twelve email inboxes. They’re twelve master keys.

That’s what 0.3% contains. Not a database of user records. Not a payment system. A set of live credentials with access to HR systems, communication infrastructure, BI tools, deployment pipelines, error monitoring, and source code.

The breach doesn’t stay inside your perimeter

Here’s what makes the integration platform threat model fundamentally different from a standard enterprise breach.

In a typical breach, the attacker gains access to your data. That’s serious. You do incident response, you notify affected parties, you remediate.

When an integration platform is breached, the attacker gains access to credentials for your customers’ environments. They never touch your customers’ networks. They never trigger an alert in your customers’ security tooling. The requests come from tokens that customers authorized. From IPs their tools have seen before.

The affected company finds out when someone tells them – or when the data is already being sold.

In the Anodot incident, a threat actor breached an AI analytics platform and used authentication tokens stored there to access Snowflake environments across a dozen customer organizations. The affected companies had done nothing wrong. Their security controls hadn’t failed. They were downstream victims of a breach they never experienced.

This is the domino effect . The first tile is your platform. The rest of them belong to your customers.

The governance questions that should keep a security architect awake

The instinct after reading an incident report is to think about controls at the point of breach: Tighter access to production systems, improved detection. Those matter.

But the deeper question is about the credential store itself – not how the attacker got in, but what they found when they arrived.

Most integration platforms can’t answer these questions with confidence:

How many credentials are you holding right now, and for whom? Not an approximation from your database. A live, queryable inventory with credential type, connected tool, scope, issuing user, creation date, and last-used timestamp.

Which of those credentials belong to users who no longer work at the company that authorized them? OAuth tokens don’t expire when employees leave. The token a developer granted to your platform in 2024, for a GitHub repo they managed, is still valid today if it was never explicitly revoked. Your system is holding a credential that the issuing company almost certainly doesn’t know about.

What do the scopes on your stored credentials actually allow – and how much of that do you use? Platforms typically request the scopes that make the integration work, or accept whatever the customer’s tool offers. Those scopes are rarely audited after issuance. A GitHub token with admin:org scope, stored because the integration needed repo:read, is sitting in your database right now.

What’s your revocation SLA? If you detect a breach at midnight, how long does it take to revoke all credentials associated with a specific customer? All credentials for a specific tool across all customers? All credentials in your system? If the answer involves any manual steps, the SLA is measured in hours, and the exfiltration window is measured in the same units.

Composio’s response to their May 2026 incident involved revoking OAuth tokens across ~100 tool integrations and asking customers to handle the rest. That’s an honest response. It’s not a fast one. And speed is the variable that determines blast radius.

What a governed credential store looks like architecturally

The solution isn’t fewer integrations or simpler architecture. It’s building the credential store with the security posture appropriate for what it actually is: a centralized store of third-party production access credentials that grows more valuable – and more dangerous – with every customer you add.

Credentials as first-class entities with lifecycle state. Every stored credential should have a lifecycle model: issued → active → dormant → expired/revoked. Transitions between states should trigger events. A credential moving from active to dormant after 90 days of inactivity should generate an alert. A credential that has never been used after 30 days should prompt a review.

Scope as a governed attribute, not a setup artifact. The scope granted at authorization time should be validated against what the integration actually requires, on an ongoing basis. Overprivileged credentials should be flagged and, where the tool supports it, downscoped via re-authorization.

Revocation as a first-class API operation. Revocation should be a single, fast, auditable operation – scoped to a customer, a tool, or the entire credential store. If it’s not, it’s a design debt that will cost you in your incident response window.

The uncomfortable truth about scale

There’s a tension that every integration platform security team lives with: the product gets better as connections deepen, and security gets harder as the credential store grows.

A platform with 10,000 connections has a manageable problem. A platform with 1.7 million has a different order of magnitude – one that requires automated governance, not periodic audits.

And the threat model shifts with scale. At 10,000 connections, you’re an interesting target. At 1.7 million connections across hundreds of tools, you’re one of the highest-value credential repositories in the systems of every company that uses your product.

The security architecture needs to reflect that. Not because something has gone wrong – but because of what you’ve built.

You’re not just holding an API key for a customer’s Slack integration. You’re holding the credential that unlocks their HR system, their deployment pipeline, their source code, their recorded sales calls, their production database – depending on which of your connectors they’ve enabled.

That’s a responsibility that deserves a dedicated security discipline. Not bolted onto standard SaaS security practices. Built for the specific problem of governing delegated credentials at scale.

At Hush Security, we work with platforms on exactly this problem – the discovery, lifecycle management, and governance of non-human identities that exist on behalf of your customers.