Topic starter
25/10/2026 11:06 am
TL;DR: AI agents that call tools need access controls, sandboxing, human review, and full tool-call observability because prompt-level safety does not stop destructive actions or privilege escalation, according to Tetrate. The security boundary for agent systems sits in infrastructure, not in the model’s instructions.
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: 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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →