LLM security best practices need runtime governance, not static controls

At a glance

What this is: This is a WitnessAI analysis of seven LLM security best practices for governing enterprise AI tools, models, and agents, with the key finding that runtime policy enforcement is now as important as discovery.

Why it matters: It matters because IAM, security, and AI governance teams must control who and what can use AI systems, what data those systems can touch, and what actions they can trigger across human and non-human workflows.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read WitnessAI's analysis of seven LLM security best practices for enterprise AI

Context

LLM security best practices are no longer a narrow model-security problem. Enterprise AI now includes employee chat tools, embedded copilots, autonomous agents, and MCP-connected workflows, which means the real governance gap is not model access alone but the combined control of data, prompts, outputs, privileges, and actions.

That gap matters for identity programmes because AI systems increasingly operate with delegated access, tool permissions, and human accountability chains. In practice, the article argues for policy enforcement that follows the AI interaction itself, rather than relying on controls that were built for static endpoints, network flows, or conventional application requests.

Key questions

Q: How should security teams govern AI agents that call APIs instead of using a UI?

A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login. The key control is to limit which APIs, data sources, and write actions the agent can chain together in one session. That keeps machine-paced behaviour inside a reviewable boundary instead of relying on human-style session assumptions.

Q: Why do keyword filters fail for enterprise AI security?

A: Keyword filters miss the way people and agents actually use AI, because risky prompts can look ordinary and sensitive output can emerge from benign input. Effective controls need intent, context, role, and destination awareness, otherwise policy enforcement remains blind to the real purpose of the interaction.

Q: What signals show that an AI governance programme is not working?

A: Warning signs include disconnected models built by different teams, repeated disputes over data ownership, inconsistent approvals and outputs that cannot be explained to stakeholders. If the organisation cannot trace which data supported a decision or who approved the model, governance is already failing at the operating level.

Q: Should organisations prioritise runtime guardrails or model review first?

A: Runtime guardrails usually deserve priority because they enforce policy during live use, when prompts, retrieval results, and agent actions are actually moving through the environment. Model review still matters, but it does not stop real-time data leakage, jailbreak attempts, or inappropriate actions at the point of execution.

Technical breakdown

Why intent-based classification matters for AI security

Keyword filters fail because prompts and responses rarely announce risk in obvious terms. Intent-based classification looks at conversational context, user role, destination model, and surrounding behaviour to decide whether a prompt is legitimate, sensitive, or policy-breaking. That approach is closer to governance than content filtering, because the control is trying to infer purpose, not merely detect forbidden words. It is especially relevant when employees paste data into public tools or when agents act through APIs that do not resemble ordinary user sessions. The technical shift is from text matching to context-aware classification across the full AI interaction.

Practical implication: classify AI traffic by intent and role before you try to enforce policy at the prompt level.

How runtime guardrails change the control model

Runtime guardrails inspect prompts before model execution and responses before users or downstream systems receive them. That bidirectional model matters because AI risk is not only in input abuse such as prompt injection or jailbreaks. It also includes unsafe or sensitive output, especially when retrieval-augmented generation pulls in internal content. Guardrails therefore operate as real-time enforcement, not post-event review. They complement network controls by reading conversational context and applying policy while the interaction is still in flight. In AI governance terms, they are the difference between declaring expectations and actually enforcing them.

Practical implication: place policy enforcement in the live request path, not only in logs or retrospective review.

Why AI agents and MCP servers need explicit governance

AI agents create a governance problem because they can call tools, invoke APIs, and carry delegated privileges beyond a single human session. That makes them closer to non-human identities than to ordinary applications. If an agent can delete records, transfer funds, or query sensitive systems, its access model must be tied to ownership, approval thresholds, and audited tool use. MCP servers add another layer because they expand the tool surface an agent can reach. Without explicit governance, delegated access grows faster than review and offboarding processes can keep up.

Practical implication: inventory agent-owned access and approved MCP connections as governed identity objects, not informal integrations.

Threat narrative

Attacker objective: The objective is to use AI interfaces and delegated access to extract data, misuse credentials, or trigger unauthorised actions at machine speed.

1. Entry occurs when employees, developers, or agents interact with AI tools outside the visibility of the traditional security stack, including embedded copilots, native apps, and API-connected agents.
2. Escalation happens when conversational prompts, prompt injection, or delegated tool calls are allowed to cross policy boundaries and reach sensitive data or privileged systems.
3. Impact follows when the AI system discloses credentials, shares sensitive content, or performs actions beyond its intended scope, creating compliance, fraud, or breach exposure.

NHI Mgmt Group analysis

Intent-based governance is now the missing layer in enterprise AI security. Traditional controls were designed to catch known patterns, not infer whether a prompt, response, or agent action is appropriate for the user or workload. As enterprise AI becomes embedded in daily work, policy has to follow intent, role, and destination rather than stop at content inspection. The practical conclusion is that AI governance must be treated as a runtime decision system, not a static policy library.

Agent-owned access is becoming a non-human identity problem. Once an AI agent can call tools, invoke APIs, or act on behalf of a user, it inherits many of the lifecycle questions long familiar in IAM and PAM: who owns it, what can it reach, when is its access revoked, and how is its behaviour audited. That makes agent governance inseparable from identity governance. Practitioner conclusion: treat agents as governed entities with explicit privilege boundaries and accountability.

Shadow AI creates a discovery problem before it becomes a model-risk problem. If security teams cannot see the sanctioned and unsanctioned tools already in use, every later control is built on partial coverage. Network-level visibility, inventory reconciliation, and classification of internal and external AI services are therefore foundational. The practical conclusion is that AI security programmes should start by establishing a living catalog of AI activity, not by writing rules for systems they have not yet found.

Runtime enforcement, not policy declaration, is what closes the gap between acceptable use and actual use. The article’s seven-practice model shows that organisations can state what should happen, but only runtime controls, bidirectional guardrails, and tamper-evident audit trails prove what did happen. That aligns with broader AI governance thinking in the NIST AI Risk Management Framework and OWASP Agentic AI Top 10, where control effectiveness must be observable. Practitioners should require evidence of enforcement, not just documented policy.

Continuous evaluation is the only stable control in a fast-changing AI threat surface. Static tests age quickly because prompts, models, retrieval sources, and agent behaviours keep changing. Red-teaming, drift monitoring, and expanding test sets turn AI security into an operating cadence rather than a launch event. The practical conclusion is that board-level AI assurance should be based on repeatable measurement, not one-time approvals.

What this signals

Enterprise AI is moving faster than the governance stack built for it, which means AI programmes will increasingly be judged on runtime enforcement, not policy language. Security leaders should expect more pressure to prove that sanctioned AI use can be measured, bounded, and audited without forcing employees back to unsanctioned tools.

AI governance debt: the longer organisations delay inventory, intent classification, and agent ownership, the more delegated access accumulates outside reviewable identity processes. That debt compounds quickly when models, copilots, and MCP-connected agents spread across business units, so the next planning cycle should prioritise enforcement evidence over tool sprawl.

For practitioners building controls around agentic AI, the practical signal is clear: connect this work to NIST AI Risk Management Framework governance functions and to the OWASP Agentic AI Top 10 so that security, legal, and AI teams share the same control vocabulary.

For practitioners

• Build a live inventory of AI activity Discover sanctioned and unsanctioned AI applications, model providers, embedded copilots, MCP servers, and agent API calls, then reconcile them against procurement records at least quarterly. Correlate each call with the identity making it so that shadow AI and unapproved integrations become visible early.
• Classify interactions by intent and role Use context-aware controls to assess what the user or agent is trying to do, whether the action fits the role, and whether the destination model or tool crosses policy boundaries. Replace keyword-only checks with behavior-aware classification for prompts, outputs, and agent actions.
• Enforce graduated AI policy actions Allow, warn, block, or route interactions based on risk, data classification, and destination model. Preserve sanctioned use by steering high-risk prompts to approved enterprise models instead of forcing blanket denial across the organisation.
• Govern agents and MCP servers as identity objects Assign human ownership to each agent, define approval thresholds for privileged actions, and maintain allow-lists of approved MCP servers and tools. Review delegated privileges on a fixed cadence so agent access does not outgrow accountability.
• Measure runtime enforcement and evaluation drift Track true-positive and false-positive rates by policy category, test guardrails against adversarial prompts on a schedule, and use the results to tune classifiers and update controls. Treat AI governance as a measurable control loop, not a launch checklist.

Key takeaways

• LLM security now depends on runtime governance across prompts, outputs, tools, and delegated actions, not just on model or network controls.
• The main risk is that AI systems behave like governed identities without being managed as such, which creates blind spots for privilege, audit, and offboarding.
• Organisations need live inventory, intent classification, graduated enforcement, and continuous evaluation if they want sanctioned AI use to remain auditable and defensible.

Key terms

• Intent-based classification: Intent-based classification evaluates what a user or system is trying to do, not just what text or file is present. In AI governance, it distinguishes routine work from risky interaction by reading context, purpose, and sensitivity. That matters when regulated data is handled conversationally rather than through formal file transfer.
• Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Agent Governance: Agent governance is the set of policies, controls, and evidence required to manage autonomous software as a non-human identity. It covers consent, tool access, lifecycle review, audit logging, and revocation so that an agent remains bounded as its workflows change.

What's in the full article

WitnessAI's full research covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanation of the seven-practice operating model for enterprise AI governance
• Concrete examples of allow, warn, block, and route policies across different departments and data classes
• Details on bidirectional runtime guardrails, including prompt inspection and response filtering
• How the audit trail design supports compliance evidence and board reporting

👉 WitnessAI's full post covers runtime controls, agent governance, and audit trail detail for teams moving AI into production.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, workload identity, and secrets management. It helps security and identity practitioners build the governance discipline needed for human and non-human access alike.