Discovery identifies where the agents are and what identities they use. Control determines which actions they may perform, on which resources, and under what conditions. An organisation can have a complete inventory and still leave dangerous privilege untouched if it lacks a policy layer that evaluates actions before execution.
Why This Matters for Security Teams
Discovery and control are often conflated, but they solve different problems in agentic environments. Discovery tells you which OWASP NHI Top 10-style agent risks you actually have: where agents run, which toolchains they touch, and what identities they present. Control is the policy layer that decides whether those actions should be allowed at all. That distinction matters because agents are autonomous, goal-driven, and able to chain tools in ways static IAM was never designed to anticipate. The OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point to runtime governance, not inventory alone, as the practical control point.
In the real world, a team can map every agent and still miss the moment when one agent starts using a legitimate token to reach data, systems, or APIs it was never meant to touch. That is why inventory without enforcement becomes documentation, not defense.
How It Works in Practice
Discovery usually starts with identifying workload identity, service accounts, MCP-integrated tools, and the secrets an agent can reach. That gives security teams visibility into what exists. Control begins when each request is evaluated in context: what the agent is trying to do, which resource it wants, whether the action matches intent, and whether the current environment justifies approval. This is where static RBAC often fails. Agents do not follow fixed user-like patterns, so pre-assigned roles can be either too broad or too brittle.
Current guidance suggests using CSA MAESTRO agentic AI threat modeling framework alongside policy-as-code and short-lived credentials. In practice, that means:
- Issue JIT credentials only for the task at hand, then revoke them automatically.
- Bind agents to workload identity rather than human-style accounts.
- Evaluate authorization at request time using intent, context, and risk signals.
- Prefer ephemeral secrets over long-lived static keys.
- Log tool use, data access, and downstream actions so discovery and enforcement can be audited together.
This maps cleanly to NHI lifecycle discipline and helps teams spot where an agent’s legitimate identity becomes an operational risk, especially when paired with AI LLM hijack breach lessons and the NIST AI Risk Management Framework. It also aligns with research showing that 80% of organisations report AI agents have already acted beyond intended scope, according to SailPoint’s AI Agents: The New Attack Surface report.
These controls tend to break down when agents operate across loosely governed SaaS tools and shared API gateways because policy decisions lose the full request context.
Common Variations and Edge Cases
Tighter control often increases latency and operational overhead, requiring organisations to balance agent autonomy against governance complexity. That tradeoff is real, especially when an agent must complete multi-step tasks across internal systems, third-party APIs, and human approval checkpoints. Best practice is evolving, and there is no universal standard for how much autonomy to allow by default.
One common edge case is an agent that is discoverable but not yet governable because it uses indirect orchestration, temporary tokens, or hidden tool calls inside a broader workflow. Another is delegated operation, where an agent acts on behalf of a user but still needs separate workload identity and its own policy boundary. In these cases, discovery tells you the agent exists, but control depends on whether the policy engine can see the action before it executes. That is why Analysis of Claude Code Security and the broader OWASP Agentic Applications Top 10 both emphasize runtime controls over cataloguing alone.
Where agents are paired with privileged automation, the difference between discovery and control becomes sharper still: discovery answers “what is connected,” while control answers “what can this agent do right now, with this token, on this resource.” In highly dynamic environments, particularly those with MCP brokers and mixed human-plus-agent workflows, that distinction is what prevents a visible agent from becoming an invisible escalation path.
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 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic apps need runtime authorization, not inventory alone. |
| CSA MAESTRO | MT-03 | MAESTRO covers threat modeling for agent identities and tool use. |
| NIST AI RMF | AI RMF governs accountability for autonomous agent behaviour. |
Apply runtime policy checks before each agent action and block tool use outside declared intent.
Related resources from NHI Mgmt Group
- What is the difference between managed identities and hardcoded secrets for AI agents?
- What is the difference between workload identity and API keys for AI agents?
- What is the difference between logging actions and logging intent for AI agents?
- What is the difference between human identity governance and AI agent governance?
