How can security teams govern AI agents without a directory for every agent instance?

They should govern the runtime, not the instance. Use workload identity, attestation, and brokered access rules that bind authorised Auth Methods to target systems. That approach covers future agent instances automatically and avoids building a brittle inventory of short-lived identities that cannot be trusted as a protection layer.

Governing Agent Runtime Instead of Chasing Every Instance

AI agents create a governance problem when teams try to treat each agent instance like a durable directory object. That model fails because agent instances are often short-lived, rapidly replaced, or multiplied across workflows and environments. The practical control point is the runtime, where the agent is authenticated, authorised, and constrained before it reaches a target system. One survey in AI Agents: The New Attack Surface report found that 92% of organisations agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

Runtime governance works because the control attaches to the action, not the inventory record. A broker can evaluate the agent’s workload identity, attestation status, execution context, and requested target before issuing access. That lets teams express policy at the boundary where the risk actually appears: which tool can be used, which system can be reached, what scope is allowed, and whether the current execution is trusted enough to proceed. In practice, many failures happen because organisations discover unsafe agent behaviour only after the agent has already been allowed to act.

How Runtime Binding, Attestation, and Brokered Access Fit Together

Governance without a per-agent directory usually relies on three linked controls: workload identity, attestation, and brokered access. Workload identity answers who or what is acting right now. Attestation answers whether the runtime matches the trusted build, policy, or execution environment. Brokered access then uses those signals to decide whether the agent may reach a target system, a data source, or a tool.

Workload identity should be issued to the runtime or execution plane, not to each ephemeral agent object.
Attestation should verify trusted code, approved environment, or signed configuration before access is granted.
Brokered access rules should bind approved auth methods to specific targets, scopes, and conditions.
Revocation should operate on policy and runtime trust signals, not on a manually maintained agent list.

This model is especially useful when agent populations change quickly, because directory-centric governance becomes stale faster than the agents themselves. It also helps with auditability: if the broker records which runtime, attestation result, and target were involved, teams can reconstruct why access was allowed without relying on a brittle catalog of transient instances. The contrast with unmanaged deployments is stark: only 52% of companies can track and audit the data their AI agents access, leaving 48% with a blind spot for compliance and breach investigation.

The operational benefit is not just scale, it is resilience. A runtime-bound model can cover future instances automatically as long as they inherit the same trusted policy and control plane. These controls tend to break down when the broker cannot reliably distinguish approved runtime state from ad hoc execution in local testing, shadow deployments, or loosely governed developer environments.

Common Variations and Edge Cases

Tighter runtime governance often increases integration overhead, so organisations need to balance stronger control against deployment speed and developer friction. That tradeoff matters most when agents are embedded in many workflows rather than run as a single managed service.

Some environments still need partial inventories for audit, incident response, or ownership tracking, but those inventories should support governance, not serve as the primary control. For highly dynamic agents, the better rule is to govern by class, environment, and policy provenance, then use attestation and broker logs to prove which runtime was trusted at the moment of access. Guidance is evolving here, but the current best practice is to treat agent identity as a runtime property that must be continuously validated, not a static record that remains trustworthy after issuance.

Where agents can reach sensitive systems or credentials, the failure mode shifts from simple misconfiguration to broad blast radius. That is why policy should be stricter for production targets than for sandbox systems, and why exceptions should be time-bound and reviewable. Teams that confuse observability with governance often end up with good reports and weak enforcement, which is the wrong order for agent control.

Risk and Threat Considerations

The main risk is uncontrolled agent action at scale: if governance depends on a directory entry for every instance, short-lived or replicated agents can slip past policy, audit, and revocation workflows. That creates blind spots for overreach, data exposure, and unauthorised system access.

Failure mechanism: An attacker or misbehaving agent can exploit stale inventory, weak runtime binding, or missing attestation to obtain access that appears legitimate in logs but is no longer trustworthy in practice. Once the control plane treats an ephemeral instance as if it were a durable identity, revocation and scope enforcement become unreliable.

Impact: Teams lose confidence in who acted, what was accessed, and whether access should still be valid. That undermines compliance evidence, slows incident response, and can allow the same control weakness to be reused across many agent instances.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	A3 — Agentic Access Control	Runtime-bound agent access is central to governing autonomous actions safely.
	A5 — Identity and Access Management	Agent governance depends on trustworthy workload identity and revocation.
Recommendation — Bind agent actions to runtime authorization and enforce scoped access at the decision point. Use runtime identity and revocation rules that do not rely on per-instance directories.
CSA MAESTRO	GOV-02 — Agent Governance	The question concerns governance controls for autonomous agents at runtime.
Recommendation — Govern agents through policy, trust, and control-plane enforcement rather than instance tracking.
NIST AI RMF	MAP 2.1 — Contextualize and Frame the AI System	Runtime policy must reflect the AI system's actual operating context and trust boundary.
Recommendation — Define the agent's runtime context and enforce access decisions against that boundary.
NIST CSF 2.0	PR.AA-01 — Identity Management, Authentication, and Access Control	Agent governance requires authentication and access control tied to current trust state.
Recommendation — Apply identity and access controls that authenticate the runtime before authorizing action.

Practitioner Guidance

What to prioritise: Build the policy around the runtime trust decision first, then decide what inventory data is still needed for audit and ownership. If the agent can act on production systems, the broker and attestation path matter more than a complete directory record.

What to verify: Confirm that access decisions depend on fresh runtime signals, not just on a one-time enrolment event. The control is weak if a copied or redeployed agent inherits access without re-establishing trust.

Practitioner takeaway: The goal is not perfect agent enumeration, it is reliable control over every action that can reach a real target.