Notifications
Clear all
Topic starter
22/06/2026 10:16 am
TL;DR: AI agents, MCP servers, and coding assistants are inheriting broad, long-lived credentials in SaaS environments, creating a faster path to breach than legacy identity hygiene, according to WorkOS. The real failure is not tool adoption but treating non-human principals like stable human identities, so blast-radius control becomes the decisive security variable.
NHIMG editorial — based on content published by WorkOS: AI identity is your next security blind spot
By the numbers:
- 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.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern AI assistants that use service accounts in production?
A: Treat them as non-human identities with explicit ownership, narrow scope, and lifecycle controls.
Q: Why do long-lived API keys create more risk for AI tools than for humans?
A: AI tools can copy, reuse, or leak credentials at machine speed, so a key that survives for months becomes a standing access path rather than a temporary convenience.
Q: What do teams get wrong about MCP server credentials?
A: They often treat MCP secrets as ordinary configuration instead of a trust boundary.
Practitioner guidance
- Inventory every non-human principal Build a complete register of service accounts, OAuth clients, API keys, and agent identities.
- Replace static secrets with short-lived credentials Move agents and MCP tools to tokens with narrow time-to-live and central issuance.
- Scope each identity to one job Issue purpose-built permissions for a single repo, system, or workflow.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- A practical checklist for inventorying service accounts, OAuth clients, and API keys tied to AI tooling.
- Implementation guidance for replacing static secrets with short-lived credentials and workload identity patterns.
- Examples of how to separate human and non-human audit baselines in production telemetry.
- A platform-team checklist for tightening scope on agents, MCP servers, and coding assistants.
👉 Read WorkOS's analysis of AI identity blind spots in SaaS platform security →
AI identity in SaaS stacks: are your controls keeping up?
Explore further
22/06/2026 11:05 am
AI identity is becoming an NHI governance problem before it becomes an AI governance problem. The article is describing service accounts, OAuth clients, and API keys, which are already familiar NHI constructs. What changes is the workload using them: agents, MCP servers, and coding assistants now move at software speed, so lifecycle drift and scope creep can spread faster than human IAM processes expect. Practitioners should treat these identities as governed machine principals, not as special-case AI exceptions.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How can organisations tell whether NHI access for AI tools is actually controlled?
A: Look for ownership, scope, rotation, and logging tied to each principal, not just a generic platform policy. If you cannot say who owns a service account, what it can reach, and when it was last reviewed, the control is not working. Principal-specific telemetry is the clearest signal that governance is real.
👉 Read our full editorial: AI identity blind spots are widening in SaaS platform security
