Topic starter
02/08/2026 11:34 am
TL;DR: Most organisations have AI acceptable-use policies, but very few can enforce them because LLM inputs, personal accounts, and agentic workflows evade traditional logging and access models, according to Cyberhaven. The governance gap is now an identity and data control problem, not just a visibility problem.
Editorial analysis by NHI Mgmt Group, based on content published by Cyberhaven: “LLM Access Controls and Audit Logging for Security Teams: A Practitioner's Guide”.
By the numbers:
- Enterprise AI adoption grew 509% year-over-year between February 2025 and February 2026.
Key questions
Q: How should security teams control LLM use when employees mix corporate and personal accounts?
A: Security teams should treat account context as part of access control, not as a reporting detail.
Q: Why do traditional logs fail to show LLM data exposure clearly?
A: Traditional logs are built around authentication, API calls, and file access, but LLM exposure often happens when the user pastes or uploads data before any response is generated.
Q: What are the signs that an LLM is failing basic governance controls?
A: Warning signs include inconsistent responses to similar prompts, weak refusal behavior, uncontrolled exposure of sensitive inputs, and poor visibility into post-deployment activity.
Practitioner guidance
- Define LLM access by role and account type Restrict coding assistants, document tools, and AI APIs to the roles that have a documented business need, and separate corporate accounts from personal-account usage on corporate devices.
- Log input events at the moment of interaction Capture pastes, file uploads, prompt sensitivity, session identifiers, and the policy state that was active when the data entered the tool, not only the later output.
- Treat personal AI accounts as an enforceable boundary Detect when a corporate device reaches a personal AI account and flag that path as a governance exception because the organisation loses contractual and audit visibility.
Bottom line: LLM governance fails when organisations rely on conventional app logging and miss the moment sensitive data enters the prompt.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:48 pm
LLM governance is now an identity-and-data boundary problem, not a logging problem. The article shows that the decisive failure is not the absence of more events in a SIEM, but the absence of control at the moment a user moves data into an LLM. That shifts ownership toward IAM, endpoint control, and data security teams working together. Practitioners should treat prompt ingress as a governed access event, not a side effect of application use.
A few things that frame the scale:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should organisations prioritise endpoint controls or tool-level audit logs for AI governance?
A: Endpoint controls should come first because they see the interaction where data actually moves into the model, including browser use, desktop tools, embedded AI features, and personal accounts. Tool-level logs are still useful, but they usually depend on the platform reporting what happened. In AI governance, the source of truth needs to sit where the data enters the workflow.
👉 Read our full editorial: LLM access controls and audit logging need endpoint visibility