Topic starter
25/10/2026 11:06 am
TL;DR: Tool-calling agents need access controls, sandboxing, human review, and full logging, Tetrate argues, because prompt-level safety does not block destructive actions or privilege escalation. Runtime authorisation, not model guidance, has to define what an agent can do.
Editorial analysis by NHI Mgmt Group, based on content published by Tetrate: “Agent Security: What NIST Wants You to Think About Before Your Agent Calls a Tool”.
Key questions
Q: Why do prompt instructions not provide enough safety for tool-using agents?
A: Because prompts cannot enforce permissions.
Q: When should organisations require human approval for an AI agent action?
A: Require human approval when the action could change infrastructure, expose sensitive data, move laterally across systems, or trigger a business-critical workflow that is hard to reverse.
Q: How should security teams govern AI agents that choose tools at runtime?
A: Security teams should treat runtime tool choice as a governed access event, not a normal application call.
Practitioner guidance
- Define agent access in IAM first Grant agents only the API operations required for one task class, and remove destructive actions from their permission set even if the model could theoretically request them.
- Move command execution into isolated sandboxes Run any agent-generated CLI or shell command inside ephemeral containers with no persistent storage, tight resource limits, and filtered network access.
- Add human approval before state-changing actions Require manual review for recommendations that would modify infrastructure, especially where rollback risk or outage impact is higher than the cost of delay.
Bottom line: Tool-calling agents are governed like executable non-human identities, which makes IAM policy and runtime containment the real security boundary.
Glossary terms: Tool-Calling Agent, Role Chaining, Sandboxed Execution, Runtime Authorisation
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:15 pm
Tool-calling agents are NHI controls wearing an AI label. The moment an agent can invoke APIs or cloud CLI commands, it becomes a governed non-human identity problem with a runtime decision layer on top. That means the security model should start with credential scope, trust relationships, and action logging rather than with model prompts. Practitioners should treat tool access as identity access, not as a chat feature.
A few things that frame the scale:
- Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
A question worth separating out:
Q: How should security teams log AI agent actions for audit and compliance?
A: Security teams should log AI agent actions as identity events, not just application events. Each record should include the human initiator, agent identity, approved session scope, tool invocation details, and any downstream delegation. That structure lets investigators prove whether the action stayed within authorised boundaries and gives compliance teams a defensible record of accountability.
👉 Read our full editorial: NIST-style agent tool security starts with infrastructure controls
This post was modified 7 days ago by NHI Mgmt Group