Agentic AI security needs monitoring and control as autonomy scales

At a glance

What this is: This is Codenotary's view that agentic AI requires monitoring, controlled autonomy and accountability as agents begin writing code, executing commands and taking production actions.

Why it matters: It matters because identity and access controls must evolve from human-centric oversight to govern software entities that can act independently at machine speed.

Context

Agentic AI changes the governance problem because the system is no longer only generating outputs. It can write software, execute commands, access infrastructure and make decisions with limited human intervention, which means traditional monitoring and access assumptions no longer cover the full risk surface.

The key issue is not just model quality but operational authority. Once agents can take action, organisations need to know which agent acted, what it accessed, which permissions it used, and whether that activity stayed inside policy boundaries. That is where identity, oversight and control converge.

This is a genuine agentic AI governance problem rather than a generic automation story.

Key questions

Q: How should security teams govern agentic AI as it moves into production?

A: Security teams should govern agentic AI as a class of non-human identity, not as a generic application feature. That means assigning ownership, scoping permissions tightly, logging every tool action, and revoking access on a defined lifecycle. Production rollout should require clear approval points for high-risk actions and continuous monitoring for drift.

Q: Why do autonomous AI agents increase security risk compared with read-only assistants?

A: Because risk comes from authorised action, not just generated output. A read-only assistant creates limited exposure, while an autonomous agent with write, trigger, or relay permissions can change records, move data, and activate workflows across systems. The more authority the agent can exercise, the more likely a small mistake becomes an enterprise-impacting event.

Q: What are the signs that an AI application has too much authority?

A: A common sign is that a single model response can write to databases, send messages, start workflows, or spend resources without a separate check. Another indicator is when the same identity can reach multiple systems even though the task only needs one narrow permission set.

Q: What is the difference between finding an AI agent and governing it?

A: Finding an agent tells you that it exists. Governing it requires ownership, approval status, credential visibility, access scope, and a review process that can remove or restrict it when conditions change. Discovery is the input; governance is the decision system that makes the discovery operational.

Technical breakdown

Why autonomous agents outgrow traditional application monitoring

Traditional application monitoring assumes a relatively stable application, predictable request flows and a narrow set of observable states. Autonomous agents break those assumptions because they can choose actions dynamically, call tools, change timing and interact with multiple systems in one task. That makes visibility harder: the control problem is not just whether the service is up, but whether the agent's sequence of actions is authorised, expected and bounded. In agentic environments, telemetry must follow the agent's decisions, not just the infrastructure it touches. See the [[L11|AI agent observability]] guide. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: instrument agent actions, tool use and decision paths rather than relying on infrastructure logs alone.

Controlled autonomous action requires task-scoped authority

AgentX points to a broader pattern in agentic AI security: some systems will not stop at recommendations and will be allowed to execute operational workflows. That shifts the core design question from output validation to action governance. If an agent can remediate, deploy or change production state, then its authority has to be scoped to the task, the context and the time window. Persistent permissions create unnecessary blast radius. The control objective is to make every meaningful action explicitly bounded and attributable, so the agent cannot silently accumulate more power than intended. See the AI Agent Authorisation Guide.

Practical implication: replace standing access for agents with task-scoped, policy-bound authority and explicit accountability.

Agent identity becomes a governance primitive in production AI

The article implicitly treats the agent itself as something that must be governed, not just the model behind it. That matters because an autonomous system that can act across infrastructure needs an identity that can be registered, authorised, monitored and retired. Without that, organisations cannot cleanly distinguish one agent from another, trace responsibility, or enforce policy consistently across environments. In practice, agent identity is what allows security teams to connect access, auditability and revocation to a specific runtime entity rather than a vague application label. See the [[L3|Agentic AI Identity Guide]] for the lifecycle model. See the Agentic AI Identity Guide.

Practical implication: assign each agent a managed identity so actions can be traced, constrained and revoked like any other privileged runtime entity.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic AI security is becoming an identity problem, not just a model-safety problem. Once an agent can write code, execute commands or access infrastructure, the security question shifts from whether the model behaves well to whether its runtime authority is bounded. That makes identity, delegation and revocation central governance controls rather than back-end implementation details. Practitioners should treat every agent as a governed actor with explicit permissions, not as a feature of the application stack.

Continuous visibility is necessary, but it is not sufficient. Monitoring tells teams what an agent did, yet governance depends on whether the action was allowed in the first place. The article points to a common failure mode in emerging AI programmes: teams add observability after they have already granted broad operational reach. The stronger design is to pair monitoring with constrained authority so the agent cannot create risk faster than security can detect it.

Agent authority drift: once a system can execute real tasks, permissions tend to expand faster than governance catches up. That creates a new security debt in which the agent's practical reach exceeds the controls originally approved for it. In the AI security programme, the question is no longer whether agents are useful, but whether their authority remains testable, revocable and auditable.

The market is moving toward a control plane for autonomous operations. The important signal here is not a product announcement, but the direction of travel: enterprises will need systems that can see, limit and explain machine-led actions at scale. That will pull identity governance, auditability and response workflows closer to the centre of AI operations. Practitioners should expect agent governance to become a board-level control concern, not a niche engineering add-on.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Agentic AI identity will become a control plane issue. As more systems gain the ability to act, the programme question shifts from model oversight to managing agent identities, delegated authority and revocation. Security teams should expect that the same governance logic used for privileged human access will need to be adapted for software actors, especially where managed agent identities touch production systems.

Visibility alone will not close the governance gap. The real challenge is that agents can move from decision to action in one runtime session, which means detection after the fact is too late to prevent the most damaging outcomes. Programmes that already have strong logging should now test whether they can actually stop or constrain an agent before it crosses a policy boundary.

Access reviews will need a new timing model. Traditional review cycles assume privileges last long enough to be examined. Autonomous systems can acquire, use and release access much faster, so identity teams should shift attention to issuance controls, delegation boundaries and runtime enforcement rather than waiting for periodic certification.

For practitioners

• Define agent identity before deployment Assign every autonomous agent a unique, managed identity so actions can be attributed, authorised and revoked across its lifecycle.
• Constrain agent permissions to the task Use task-scoped access and explicit policy checks so agents can only reach the systems and actions required for the current workflow.
• Log tool use and decision paths Capture each agent's tool calls, resource interactions and action sequence so security teams can reconstruct behaviour after an incident or anomaly.
• Separate recommendations from execution Keep advisory agents and action-taking agents under different governance rules so recommendation workflows do not inherit production control by default.

Key takeaways

• Autonomous agents change the security problem from monitoring software to governing software that can act.
• The central control question is whether each agent has bounded authority, traceable actions and revocable access.
• Identity, delegation and auditability are now core requirements for safe agentic AI operations.

Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Security Guide

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Task-Scoped Access: Task-scoped access is permission granted for one defined purpose and removed once the task is complete or the session expires. For non-human identities, it reduces standing privilege and limits how long an attacker can exploit a stolen credential.
• Runtime authority: Runtime authority is the permission an AI system has while it is actively deciding and acting, not just when it is approved. In governance terms, it is the point where access, tool use, and action scope become operational, which is why build-time review alone cannot prove safety.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and workload identity. It helps practitioners connect identity controls to the operational risks raised by autonomous AI systems.