Notifications
Clear all
Topic starter
06/07/2026 9:47 am
TL;DR: AI-native enterprises rely on agents, workflows, APIs, and tokens that act continuously across cloud and SaaS systems, making identity the primary security control plane rather than network location or application boundaries, according to Token Security. The old model of static permissions and periodic reviews breaks because runtime access decisions, ownership, and lifecycle control now have to match machine speed.
NHIMG editorial — based on content published by Token Security: Designing an Identity-First Security Architecture for AI-Native Enterprises
By the numbers:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams govern AI-native access paths across cloud and SaaS systems?
A: They should govern AI-native access by mapping every agent, service account, token, and OAuth grant to an owner, an allowed scope, and a revocation path.
Q: Why do static IAM controls fail in AI-native enterprises?
A: Static IAM controls fail because they assume access is relatively stable and can be reviewed after the fact.
Q: What do security teams get wrong about token governance for machine identities?
A: They often treat tokens as implementation detail instead of the primary bearer of machine privilege.
Practitioner guidance
- Map AI-native access paths end to end Inventory agents, service accounts, tokens, OAuth grants, and event-driven workflows together so ownership and privilege are visible across the full execution chain.
- Shift critical controls to runtime enforcement Apply policy at execution time for APIs and SaaS actions instead of relying on static roles and quarterly access reviews.
- Treat tokens as governed identities Assign owners, enforce expiration, scope permissions tightly, and automate revocation when the workload, integration, or agent changes.
What's in the full article
Token Security's full blog covers the operational detail this post intentionally leaves for the source:
- The article's architecture diagram showing how the identity layer, policy layer, runtime enforcement, and telemetry fit together in AI-native environments
- The token governance maturity model that contrasts traditional IAM with identity-first controls such as enforced expiration and automated revocation
- The anti-pattern list that distinguishes temporary access from actually revoking access in machine workflows
- The article's practical measurement lens for tracking active non-human identities and time-bound credentials
👉 Read Token Security's analysis of identity-first security architecture for AI-native enterprises →
AI-native enterprise security architecture: what IAM teams must change?
Explore further
06/07/2026 10:04 am
Identity-first security is now the only control model that matches AI-native enterprise behaviour. The article is right that network location and static boundaries cannot follow software that moves across cloud and SaaS ecosystems. The discipline shift is not cosmetic. It moves security from where traffic comes from to what identity is doing at runtime, which is the only lens that can keep pace with agents, tokens, and service accounts.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Another 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage, which shows how exposed machine credentials turn into operational loss.
A question worth separating out:
Q: How do you know if identity-first security is actually working in AI-native environments?
A: Look for measurable runtime control, not just policy documents. Useful signals include the number of active non-human identities, the percentage of time-bound credentials, revocation speed for unused access, and how much access is enforced continuously rather than reviewed later. If those metrics are weak, the control plane is still static.
👉 Read our full editorial: Identity-first security architecture for AI-native enterprises
