Topic starter
22/07/2026 4:37 pm
TL;DR: AI agent architectures are converging on similar runtime-control language while solving different problems: CrowdStrike’s Falcon AIDR plus Continuous Identity focuses on risk-adaptive access revocation, while EnforceAuth evaluates deterministic transaction authorization against business context, according to EnforceAuth. The practical issue is not which brand is stronger, but that access retention and action permission are distinct decisions that enterprise IAM cannot collapse into one.
Editorial analysis by NHI Mgmt Group, based on content published by EnforceAuth: “Two Control Planes, Two Questions: A Technical Comparison of Falcon AIDR and EnforceAuth”.
Key questions
A: Treat access retention and action approval as separate controls.
Q: Why do AI agents need policy-based authorization even when detection is in place?
A: Detection can identify suspicious behaviour, but it cannot decide whether a specific business action is allowed under tenant rules, delegated authority, or segregation of duties.
Q: What breaks when runtime authorization is handled only through access revocation?
A: You can shorten the lifetime of a compromised or risky session, but you still cannot stop the first unauthorized action if the identity is currently clean-risk.
Practitioner guidance
- Separate access retention from action permissioning Define one control path for revoking or retaining agent sessions and a different one for evaluating whether each business action is allowed.
- Move business-rule decisions to the resource boundary Evaluate tenant scope, segregation of duties, delegated authority, and application state where the write or mutation happens, not only where the prompt is observed.
- Treat delegation as a policy problem per hop Check whether each delegated step narrows authority, preserves provenance, and blocks forbidden combinations of capabilities across sub-agents.
Bottom line: AI agent governance now splits into two runtime questions, whether access should continue and whether a specific action should be allowed.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
22/07/2026 4:41 pm
Two runtime control planes are now the right model for agentic governance: one governs whether an identity retains access, and the other governs whether a specific action is permitted. Those are not interchangeable decisions, even when they are delivered through similar control-plane language. For practitioners, the architectural mistake is collapsing risk-adaptive access management and transaction authorization into one layer.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How should teams govern delegated AI agent actions without losing attribution?
A: Use a separate runtime identity for the agent and tie it to the sponsoring human in the audit trail. That lets teams answer who authorised the action, which agent executed it, and which system was touched without collapsing everything into one user session.
👉 Read our full editorial: Runtime authorization for AI agents needs two control planes