Notifications
Clear all
Topic starter
30/07/2026 10:51 pm
TL;DR: AI agents can turn a single hidden instruction into data exfiltration when private data, untrusted content, and external communication converge at runtime, according to ConductorOne and Simon Willison's lethal trifecta framing. The governance problem is not just access provisioning but controlling each tool call before execution.
NHIMG editorial — based on content published by ConductorOne: Introducing agent runtime governance: intent-based access control for AI agents
Questions worth separating out
Q: How should security teams govern AI agent tool calls without exposing credentials?
A: Security teams should place credentials in a separate execution layer, not in the model context, and bind every tool call to a distinct agent identity.
Q: Why do AI agents create governance problems that normal access reviews miss?
A: AI agents can read, copy, transform, and re-share data after the original access decision, so a static review of entitlements does not capture downstream impact.
Q: What breaks when an agent can reach private data and external channels at the same time?
A: The lethal trifecta creates a path from normal retrieval to exfiltration.
Practitioner guidance
- Route every agent tool call through a single enforcement point Centralise decisioning so the call is classified before execution, policy is applied consistently, and every outcome is tied to the governed agent identity and owner.
- Scope agent toolsets to the minimum job-required actions Give support agents only support tools, data agents only read and query tools, and keep destructive actions outside the default toolset unless there is a specific governed need.
- Use observe mode before enforcing runtime policies Start with projected decisions, review where policies would block, hold, or redact, then tune the policy and move to enforcement once the impact is understood.
What's in the full article
ConductorOne's full blog covers the operational detail this post intentionally leaves for the source:
- How observe mode projects block, hold, and redact outcomes before enforcement
- The policy logic used to score the lethal trifecta across live agent sessions
- How the governed AI gateway classifies MCP servers and internal tools
- The audit record structure that ties each decision to an agent identity and owner
👉 Read ConductorOne's post on agent runtime governance and tool-call controls →
AI agent runtime governance: are tool calls actually controlled?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
30/07/2026 10:57 pm
Runtime governance is now the missing layer between entitlement and execution. Traditional IAM and PAM tell you what an agent is allowed to hold, but they do not decide whether a specific tool call is safe in the moment. That gap matters because AI agents can convert legitimate access into harmful action without changing identity state. The implication is that agent governance has to be evaluated at the action boundary, not only at provisioning time.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how often machine identity programmes still lack basic inventory control.
A question worth separating out:
Q: Who is accountable when an AI agent makes a risky decision?
A: Accountability should rest with the organisation that authorised the agent, the human owner of the workflow, and the control process that allowed the behaviour. If an agent can act independently, the programme must preserve attribution, action logs, and policy decisions so audit and remediation are possible after the event.
👉 Read our full editorial: Intent-based access control for AI agents needs runtime governance
