Notifications
Clear all
Topic starter
06/06/2026 1:33 am
TL;DR: APIs that serve humans, scripts, and AI agents need self-serve keys, scoped permissions, fast validation, and immediate revocation, according to WorkOS. The governance issue is not issuance but control of who can create, use, and retire keys without turning API access into standing privilege.
NHIMG editorial — based on content published by WorkOS: How to add API key support to your app
Questions worth separating out
Q: How should security teams handle scoped API keys for scripts and AI agents?
A: Treat scoped API keys as non-human identities with a defined lifecycle.
Q: Why do API keys create governance issues even when they are easy to issue?
A: Because issuance is only the first control point.
Q: What breaks when revoked API keys do not fail immediately?
A: A residual validation window leaves a credential usable after the organisation believes access has ended.
Practitioner guidance
- Separate key models by actor and use case Use user-scoped keys for personal automations and organization-scoped keys for shared pipelines or backend integrations.
- Enforce permissions at every protected route Validate the bearer token and then check the permissions array against the endpoint requirement, such as read versus write.
- Wire key lifecycle events into security operations Send create and revoke events into logging, alerting, and review workflows so security teams can see who created access, when it was last used, and when it ended.
What's in the full article
WorkOS's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step widget integration for self-serve key creation and revocation in a SaaS settings page
- Backend code paths for validating bearer keys in Next.js and Express without building custom plumbing
- Permission setup patterns for user-scoped and organization-scoped keys in the WorkOS dashboard
- Event subscription and audit-log wiring for api_key.created and api_key.revoked lifecycle events
👉 Read WorkOS's guide to adding self-serve API key management to your SaaS →
AI agents and scripts on APIs: what scoped keys change for IAM?
Explore further
06/06/2026 2:44 am
API key governance is no longer a developer convenience problem. Once humans, scripts, and AI agents all use the same API surface, the control question becomes who can create, scope, and retire access without creating standing privilege. That shifts API keys from a simple authentication primitive into a lifecycle-managed identity control, which is exactly how IAM teams should treat them.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
- Internal repositories are 6x more likely to contain secrets than public ones, at 32.2% versus 5.6%, which means private code is not a safe assumption for credential governance.
A question worth separating out:
Q: Who should own org-scoped API keys versus user-scoped API keys?
A: User-scoped keys should belong to the individual whose actions they represent, while org-scoped keys should belong to the organisation and be governed by admin roles. The key test is whether offboarding a person should automatically end the credential or leave a shared integration intact.
👉 Read our full editorial: API key support for AI agents and scripts needs scoped governance
