AI identity is your next security blind spot

If you run a B2B SaaS platform, the question isn't whether agents, copilots, and MCP servers in your environment will get compromised. It's how much damage they can do when one does.

The attack surface here isn't hypothetical. The same credential hygiene failures that turned the 2021 Codecov breach into a supply chain incident are now playing out with AI tooling, just faster and at greater scale. Developers are wiring coding assistants into production stacks with API keys that inherit their full permissions. MCP servers are being issued OAuth credentials that live in .env files for months. Agents are running on service accounts with scopes sized for "make it work" rather than least privilege.

When one of those credentials leaks, and it will, the question is whether it expires in minutes or sits live for 18 months.

What "AI identity" actually maps to in your IAM system

There are three patterns showing up consistently in B2B SaaS stacks right now.

• Service accounts for agents. A long-running agent that reads tickets, drafts replies, and hits your internal APIs needs some identity. The common shortcut is a service account with a static secret and broad scopes. That secret ends up in a config file and outlives the developer who created it.
• OAuth client credentials for MCP tools. Every MCP server you expose to a model is an OAuth client. Those client_id and client_secret pairs propagate into CI variables, developer laptops, and deployment configs. Unlike human sessions, nobody notices when they go stale or get over-shared.
• API keys handed to coding assistants. The fastest way to wire Claude, Cursor, or Copilot into your stack is to paste an API key into a config. That key inherits whatever the developer who minted it can do, which is usually far more than the assistant needs.

In all three cases you have a non-human principal, a long-lived secret, and no meaningful scope enforcement. That combination is the problem.

The controls worth shipping this quarter

None of these are exotic. They're the boring work that shrinks blast radius when a credential leaks.

• Inventory every non-human principal. You can't scope what you can't see. Pull a list of every service account, OAuth client, and API key in your identity provider and application database. Tag each one: who owns it, what AI system uses it, what it can do. The most common first finding is orphaned keys minted by ex-employees for tools nobody remembers.
• Replace static secrets with short-lived credentials. A client_secret sitting in a .env file for 18 months is the worst kind of identity. Move agents and MCP tools to short-lived tokens: OAuth client credentials with short TTLs, or workload identity federation where the agent exchanges a platform-issued attestation for a fresh access token. On AWS this is IAM Roles Anywhere. On GCP it's Workload Identity Federation. The pattern is the same: no long-lived secret, no long exposure window. If a token leaks, the damage window is minutes, not months.
• Scope tokens to the job, not the user. When a developer wires up a coding assistant, they tend to hand it a token with their own permissions. That token can now read every repo, every secret, every customer record they can. Mint purpose-built tokens per agent, per task, with the narrowest scope that makes the workflow function. "Read issues in this one repo" beats "act as Alice."
• Sync service identities through your directory. Treat agent and tool identities as first-class entries in your directory, not side-channel records in a YAML file. When a developer leaves, their human account gets deprovisioned through SCIM. The service accounts they minted should follow the same lifecycle. Directory-synced service identities are how you keep your inventory from rotting.
• Log and alert on non-human principals separately. Human sessions and agent sessions have fundamentally different baselines. A service account making 50,000 API calls in an hour is either doing its job or exfiltrating data. Your detection rules need to distinguish the two. Split your audit logs by principal type and build separate alerting thresholds. A spike that looks normal for a user is an incident for a service account.

The actual goal is blast radius, not prevention

None of this stops a determined attacker from compromising a token. The point is that when they do, the token expires quickly, touches only a narrow slice of your system, and shows up in an audit log you actually monitor. That's the difference between a contained incident and a breach that reaches customer data.

The teams getting this right aren't running exotic zero-trust architectures. They're doing unglamorous work: inventorying principals, shortening credential lifetimes, tightening scopes, and routing service identities through the same directory that governs their humans.

Pick one item from this list and ship it this sprint. The exposure surface isn't shrinking on its own.