TL;DR: Security teams are using AI agents most often for repository context, dependency tracing, and cross-repository investigation, not just exploitability checks or violation fixing, and 94 of 100 interactions required at least one tool invocation, according to Cycode research. The pattern suggests agentic security is becoming a workflow accelerator for high-friction analysis, but it also raises governance questions about how much code, data, and remediation authority these systems should hold.
At a glance
What this is: Cycode’s analysis of 100 Maestro conversations shows practitioners using an AI agent for code context, dependency tracing, and investigative security work more often than simple fix or verdict requests.
Why it matters: For IAM, PAM, and NHI teams, the shift matters because AI agents are now operating as privileged workflow actors that can query repositories, inspect live data, and influence remediation decisions.
By the numbers:
- Across the first 100 conversations, Cycode estimated that Maestro saved 60 hours by handling tasks that would otherwise require manual investigation.
- Of the 100 conversations, 94 required Maestro to invoke at least one agent skill beyond a plain text response.
👉 Read Cycode’s analysis of the first 100 Maestro security conversations
Context
AI agent security is no longer being used only for narrow question answering. In practice, teams are asking agents to investigate repositories, trace dependencies, query detection data, and summarise findings that would otherwise require a chain of manual lookups across tools and systems.
That matters for identity and access governance because an AI agent that can inspect code, query live telemetry, and trigger remediation is acting with delegated authority. In NHI terms, the control problem is not just what the model can say, but what the agent can reach, what it can do, and how much standing privilege it carries while doing it.
Key questions
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.
Q: Why do AI tools create new access governance risks for security teams?
A: AI tools often sit close to mail, data, and response systems, which makes their permissions unusually broad. The risk is not only misuse by attackers, but also scope creep as teams add more data, actions, and integrations without revisiting ownership, approval, and revocation. That is a classic identity governance failure.
Q: What signals show that an AI agent is operating outside its intended purpose?
A: Look for mismatches across identity, data, model behaviour, posture, and environment. A clean authorization trail is not enough if the agent starts touching unrelated data, follows injected instructions, drifts from its known configuration, or continues acting in a way that does not fit the task.
Q: What should organisations do before letting AI systems execute remediation tasks?
A: They should define which tasks are eligible for delegation, which require human approval, and which systems are out of scope. They should also test rollback, capture audit evidence, and check post-change state so execution can be verified. Without those controls, delegated remediation becomes unbounded privilege rather than governed action.
Technical breakdown
Why repository context is now the dominant AI security use case
The most common agentic security workflow is not remediation but context reconstruction. Practitioners need to understand code they did not write, in repositories they do not own, across pipelines they did not build. An AI agent can assemble that context faster by combining repository search, dependency tracing, and runtime analysis into one conversational flow. That changes security operations from linear lookup to guided investigation. The underlying architectural shift is important: the agent is not just generating text, it is orchestrating evidence collection across multiple systems.
Practical implication: treat repository and pipeline access as delegated operational authority, not a chat feature.
How sequential tool calls change the risk profile of AI agents
Cycode’s data shows that most meaningful conversations required at least one tool invocation, and the hardest ones required three or more sequential calls. Each call expands the trust boundary because the agent is no longer answering from static context, it is deciding what to query next and how to combine results. That creates a governance issue familiar to IAM and PAM teams: stepwise access can still become broad access if each step inherits prior privileges and approvals are not re-evaluated. The risk is compounded when the agent can chain planning, querying, synthesis, and remediation without human checkpoints.
Practical implication: scope every tool call to a task boundary and re-authorise before remediation or cross-system traversal.
Why clarification is becoming the core value of agentic security
The strongest pattern in the dataset is not speed alone. It is reduced ambiguity. Security teams want answers like whether exposure is real, which findings are exploitable, and which dependencies matter now. That is a governance problem as much as a detection problem, because clarity determines whether the next action is alerting, triage, or remediation. For AI security programmes, this means the success metric should not be raw automation volume. It should be whether the agent compresses time to decision without widening the blast radius of delegated access.
Practical implication: measure AI agent value by decision quality and containment, not by the number of tasks automated.
NHI Mgmt Group analysis
AI security agents are becoming delegated control points, not just interfaces. When a system can query live data, inspect code, and execute remediation, it is functioning like an operational identity with scoped authority. That makes access governance, approval boundaries, and auditability part of the agent design itself. For identity teams, the question is no longer whether the model is accurate enough, but whether its delegated permissions are bounded tightly enough to withstand misuse.
Context retrieval is now the first major use case for agentic security, and that changes the identity problem. The article shows practitioners using an agent to reconstruct repository and dependency context that humans would gather manually. In identity terms, this is a machine identity problem because the agent must authenticate to many systems to do the work. The control challenge is least privilege across many short-lived interactions, not just secure prompt handling. Practitioners should map agent access like any other privileged workload.
Sequential authority chaining: is the named risk emerging here, where multiple small tool calls accumulate into broad operational power. The agent plans, queries, analyzes, and synthesizes in sequence, which means each step depends on the privileges granted to the last. That weakens traditional review models that assume a single request maps to a single decision. The practical conclusion is clear: governance has to track the whole task chain, not just the initial prompt.
AI agents reduce time to clarity only when data access is already governed. The article’s value case depends on the agent reaching repositories, logs, and detection data quickly enough to answer hard questions. If those sources are poorly classified or overexposed, the same capability can accelerate misuse as easily as investigation. The right boundary is not whether agents may act, but which data domains they can reach and under what identity assurance.
This is where NHI and agentic AI governance converge. An agent that can inspect code and drive remediation should be managed as a non-human identity with lifecycle, entitlement, and revocation controls. That means the identity programme must extend beyond human IAM and into machine-to-machine delegation, with explicit ownership for every agent skill. Practitioners should align this class of access with NHI governance rather than ad hoc automation policy.
What this signals
AI security teams should expect agentic workflows to become more operational, not less. As agents move from answering questions to traversing repositories and live telemetry, programme owners will need explicit rules for task scope, escalation, and rollback so investigation speed does not outpace governance.
Sequential authority chaining: the next governance problem is the accumulation of small, legitimate tool calls into one broad capability set. That means access reviews must move from static entitlement lists to task-based observation, with reference material such as the OWASP Top 10 for Agentic Applications 2026 and NIST AI Risk Management Framework used to anchor control design.
If AI agents are saving investigation time, the programme question becomes whether that time saving is repeatable under tighter guardrails. Security teams should prepare for more agent access to code, logs, and remediation paths, and pair that with NHI lifecycle discipline so the agent’s permissions stay narrow, reviewable, and revocable.
For practitioners
- Define agent task boundaries Limit each AI agent workflow to a single investigation or remediation objective, and force re-approval before the agent crosses into another repository, environment, or response phase.
- Inventory every tool the agent can call Document repository access, detection queries, graph searches, and remediation actions as distinct privileges so you can review them like a machine identity entitlement set.
- Require human sign-off for remediation paths Allow the agent to triage and explain findings, but gate any code change, deletion, or ticket auto-closure behind explicit human approval.
- Measure clarity outcomes, not just automation volume Track whether the agent shortens time to a defensible decision, reduces investigation churn, and lowers false escalation rates across security workflows.
Key takeaways
- AI security agents are already being used as investigative operators, not just conversational assistants.
- The main governance issue is delegated access across multiple systems, not only the quality of the agent’s answers.
- Security teams should manage agent privileges like non-human identities, with task boundaries, review points, and revocation controls.
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 OWASP Non-Human Identity Top 10 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 | The article centres on agentic workflows, tool use, and delegated action. | |
| NIST AI RMF | MANAGE | The post is about governing AI systems that take action across tools. |
| NIST CSF 2.0 | PR.AC-4 | Repository and tool access must align with least privilege and access governance. |
| OWASP Non-Human Identity Top 10 | NHI-03 | The agent behaves like a non-human identity with lifecycle and privilege concerns. |
Map agent tool permissions and escalation paths against agentic AI controls before enabling remediation.
Key terms
- Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
- Sequential Tool Call: A chain of agent actions where one tool invocation informs the next, such as planning, querying, analysing, and synthesising. This creates a larger trust boundary than a single request because privileges can accumulate across steps unless each step is separately constrained.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- Context Reconstruction: Context reconstruction is the process of combining identity data, logs, vault events, and application telemetry to understand what a non-human identity is, what it can reach, and why it exists. It turns raw inventory into governance-relevant evidence that can support ownership, attestation, and risk prioritisation.
What's in the full article
Cycode’s full blog post covers the operational detail this post intentionally leaves for the source:
- Specific examples of the repository and dependency investigations that Maestro handled across enterprise environments
- The step-by-step tool chain used for exploitability checks, live detection queries, and remediation-oriented workflows
- The kinds of security questions practitioners asked in natural language versus through standard interface filters
- The article’s own estimate of time savings across the first 100 conversations and how that was calculated
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It gives security and identity practitioners a practical foundation for governing delegated access across human and non-human systems.
Published by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org