Notifications
Clear all
Topic starter
02/08/2026 9:46 am
TL;DR: AI security governance has moved from policy to runtime enforcement as autonomous agents, MCP-connected tools and chained actions create risks traditional application controls miss, according to Akto. The decisive issue is not model output alone, but whether discovery, accountability and guardrails can keep pace with agent behaviour.
NHIMG editorial — based on content published by Akto: AI Security Governance: Frameworks, Enforcement and Real-World Controls
By the numbers:
- 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%).
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
Questions worth separating out
Q: What breaks when AI agents chain access across tools and services?
A: The original approval no longer describes the effective access path.
Q: Why do AI agents create governance problems that normal access reviews miss?
A: AI agents can read, copy, transform, and re-share data after the original access decision, so a static review of entitlements does not capture downstream impact.
Q: How do security teams know if AI governance is working?
A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent.
Practitioner guidance
- Inventory every agent, model and MCP connection Create a live inventory that records each AI system, the tools it can call, and the data sources it can reach.
- Assign explicit ownership for agent access decisions Put AI tool and data access decisions into a RACI model so one accountable owner approves each new delegation path.
- Enforce runtime guardrails on tool use Limit which actions an agent can take, when it can take them and which outputs can leave the environment.
What's in the full article
Akto's full post covers the operational detail this post intentionally leaves for the source:
- Framework-by-framework guidance for translating NIST AI RMF and ISO 42001 into an operating model
- Discovery workflow details for cataloguing MCP servers, AI agents and connected tools across cloud and endpoint environments
- Runtime guardrail examples for filtering inputs, limiting tool calls and constraining output behaviour
- Incident response considerations for prompt injection, data leakage and model behaviour drift
👉 Read Akto's analysis of AI security governance for agentic and LLM applications →
AI security governance and agentic workflows: are your controls keeping up?
Explore further
02/08/2026 12:38 pm
AI security governance is becoming an identity problem as much as a model-risk problem. Once an agent can authenticate to tools, data stores or MCP servers, it behaves like a non-human identity with delegated authority. That means IAM, PAM and lifecycle controls become part of AI governance, not an adjacent concern. Organisations that treat agent access as application configuration will miss the real control point, which is identity, privilege and revocation.
A question worth separating out:
Q: Which controls matter most when governing autonomous AI systems?
A: The most important controls are discovery, least privilege, runtime guardrails, audit logging and a clear decision owner for access changes. Together they reduce the chance that an agent can act outside approved scope and they give security teams evidence when an incident occurs.
👉 Read our full editorial: AI security governance fails when agents outpace control planes
