Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Generative AI and NHI governance: what IAM teams need to know


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 2273
Topic starter  

TL;DR: Generative AI RAG deployments expand the non-human identity attack surface through service accounts, access keys, SAS tokens, and stale secrets that can expose or poison grounded data, according to Oasis Security. The governance problem is not AI novelty but unmanaged machine access that turns data integrity and privacy into identity control failures.

NHIMG editorial — based on content published by Oasis Security: Securing Generative AI with Non Human Identity Management and Governance

Questions worth separating out

Q: How should security teams govern non-human identities in generative AI workflows?

A: Security teams should inventory every machine identity that touches prompts, retrieval, storage, and update paths, then assign ownership, expiry, and least-privilege scope.

Q: Why do RAG architectures increase non-human identity risk?

A: RAG increases NHI risk because the system depends on credentials to retrieve and often update the data that shapes responses.

Q: What breaks when service accounts and API keys are left unrotated in AI systems?

A: Unrotated secrets extend the attack window long after the original deployment decision is forgotten.

Practitioner guidance

  • Inventory every AI data-access credential Build a register of service principals, API keys, SAS tokens, and storage credentials used by RAG and adjacent AI workflows.
  • Separate read and write permissions on grounding sources Do not let the same identity both retrieve and modify the data that influences model output.
  • Rotate and expire machine secrets by policy Replace long-lived access keys and stale service principal secrets with short-lived credentials where possible, and enforce rotation where fixed credentials remain unavoidable.

What's in the full article

Oasis Security's full blog post covers the operational detail this analysis intentionally leaves for the source:

  • Implementation examples for Azure blob storage access methods including SAS tokens, service principals, and access keys.
  • Specific NHI hygiene failures the article highlights, such as stale service principals and unrotated full-access keys.
  • The vendor's perspective on visibility, lifecycle automation, and remediation for AI-related machine identities.
  • The Microsoft AI data exposure incident referenced as an illustrative case for SAS token risk.

👉 Read Oasis Security's analysis of securing generative AI with NHI governance →

Generative AI and NHI governance: what IAM teams need to know?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 4 weeks ago
Posts: 742
 

Generative AI does not create a new identity category, it exposes an old one that was already under-governed. RAG systems rely on the same machine credentials that already trouble cloud and SaaS programmes, including service accounts, tokens, and storage keys. The difference is that those identities now sit on the path to business-critical answers, which raises the consequences of poor lifecycle control. Practitioners should treat AI adoption as an NHI maturity test, not a special case.

A few things that frame the scale:

  • 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% only partial visibility, according to The State of Non-Human Identity Security.
  • Our other research shows: 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, including 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.

A question worth separating out:

Q: Who is accountable when AI output is influenced by tampered grounding data?

A: Accountability should sit with the teams that own the data source, the machine identity, and the AI workflow, because the failure spans all three. Identity governance, data governance, and application ownership must align on who can read, who can write, and who can revoke. Without that mapping, incident response becomes guesswork instead of containment.

👉 Read our full editorial: Securing generative AI requires governed non-human identities



   
ReplyQuote
Share: