Topic starter
05/10/2026 6:49 pm
TL;DR: Saviynt says AI agents can make thousands of tool calls in the time it takes a human to review one, so access control now has to judge both whether a tool is permitted and whether each specific call matches the agent’s intent and payload. That makes runtime alignment, not static approval, the governing problem for agent access.
Editorial analysis by NHI Mgmt Group, based on content published by Saviynt: “Zuma: Keeping AI Agents on Task, Before and During Every Tool Call”.
Questions worth separating out
Q: How should security teams stop AI agents from using approved tools to exfiltrate data?
A: Security teams should assume approved tools can be abused and apply task-scoped restrictions, behavioural monitoring, and strong separation between the agent and writable configuration state.
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 access risk?
A: Many teams focus on the model while ignoring the identity path that reaches it.
Practitioner guidance
- Define agent purpose at onboarding Require each AI agent to have an explicit stated purpose, tool inventory, and prohibited action list before it is allowed to call production systems.
- Validate every tool call against the payload Inspect the runtime arguments on each invocation so injected commands, off-scope values, and suspicious destinations are blocked before execution.
- Separate designtime and runtime governance Use onboarding checks to prevent unnecessary tools from being attached, then use inline runtime checks to stop misuse of approved tools.
What's in the full article
Saviynt's full blog covers the implementation detail this post intentionally leaves for the source:
- The two-stage classifier architecture that separates designtime intent checks from runtime payload checks
- The training and inference design choices behind the custom encoders and explanation model
- The four verdict levels and how each maps to block, review, log, or proceed actions
- The examples showing how the model handles valid tools used with invalid payloads
👉 Read Saviynt’s analysis of explainable AI agent alignment and runtime intent checks →
AI agent alignment: are your controls keeping up with runtime intent?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
05/10/2026 6:49 pm
Agent intent is now an identity boundary, not a policy footnote: The article is really about whether governance can keep up with software that chooses actions through tools. Once an agent can call databases, APIs, and infrastructure services, the security question is no longer only entitlement scope but whether the actor’s current behaviour still matches its declared purpose. That makes intent a first-class access attribute, not an afterthought for review.
A few things that frame the scale:
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How do you know whether AI agent alignment controls are working?
A: Look for a control that can separate aligned calls, borderline cases, and clear misalignments without overwhelming analysts. If the system cannot explain why a call was flagged, or if false positives are so high that teams ignore alerts, the governance model is not operating cleanly.
👉 Read our full editorial: Explainable agent alignment shifts AI access control from tools to intent