Notifications
Clear all
Topic starter
14/09/2026 10:10 am
TL;DR: AI agents can act within granted permissions and still make harmful decisions, and Linx Security argues the real gap is between access governance and runtime judgment, not just unauthorized access. The article shows why organisations need clear autonomy boundaries, ownership, and independent approval for consequential actions because least privilege alone cannot govern intent or context.
NHIMG editorial — based on content published by Linx Security: AI Access Control Sep 10, 2026 Who Is Responsible When an AI Agent Does Something It Was Allowed to Do?
By the numbers:
- 53% of surveyed organizations had experienced agents exceeding their intended permissions, while 47% reported an AI-agent-related security incident.
Questions worth separating out
Q: What breaks when AI agents are not governed at runtime?
A: Without runtime governance, an agent can shift behaviour after provisioning and still execute actions that were never reviewed in context.
Q: Why do approved AI agents still create security risk in enterprise environments?
A: Because approval is not the same as authorisation for every action.
Q: What do security teams get wrong about AI agent identity governance?
A: They often assume human IAM patterns can be reused with minor adjustments.
Practitioner guidance
- Separate entitlement approval from runtime approval Define which agent actions are always allowed, which require additional context, and which need human or policy approval before execution.
- Assign explicit ownership for each agent’s business intent Name a business owner, a security owner, and a technical owner for every production agent so authority does not drift as integrations expand.
- Treat coarse application permissions as a governance defect Where the application cannot express the intended scope, document the gap as a risk rather than accepting the broadest technically available permission.
What's in the full article
Linx Security's full blog post covers the operational detail this post intentionally leaves for the source:
- How to distinguish access granularity from delegated judgment in production agent workflows
- Examples of runtime approval thresholds for refunds, data updates, and security-impacting actions
- Guidance on ownership handoffs across business, security, application, and engineering teams
- The role of identity data layers in keeping agent authority aligned to business intent
👉 Read Linx Security's analysis of AI agent access control and accountability →
AI agent governance: are your controls separating access from judgment?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
14/09/2026 10:11 am
Permission governance does not equal judgment governance: The article captures a control gap that identity programmes still understate. Access reviews and least privilege can prove that an agent was allowed to act, but they cannot prove that the action was appropriate in context. That is why AI agent governance has to separate delegated authority from delegated judgment, with the latter treated as a distinct control surface.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How do teams decide whether an AI agent needs human approval?
A: Use the sensitivity of the action, not the cleverness of the model, as the decision point. If the agent can change records, move funds, send external messages, or access regulated data, human approval or an independent policy engine should remain in the path. The more irreversible the action, the less autonomy the agent should have.
👉 Read our full editorial: AI agent governance fails when permission and judgment diverge
