Authenticated AI agents still need action-level authorization

At a glance

What this is: This is a ThreatLocker analysis of why authenticated AI agents can still act unsafely when authorization, context, and device trust are not continuously rechecked.

Why it matters: IAM, PAM, and NHI teams need to treat agent authentication as only one control layer, because runtime action approval and least privilege now determine whether an agent can safely operate.

By the numbers:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.

Context

Authentication answers who or what is connecting, but it does not answer whether the requested action is safe, necessary, or within task scope. For AI agents, that distinction matters because the same identity can read, write, send, delete, execute, and elevate across multiple systems once permitted to act.

The security gap is not whether an agent can log in, but whether the programme can keep verifying the user, the agent, the device, the source of the instruction, and the exact action requested. That is an identity governance problem as much as it is an access control problem, especially when agents inherit broad permissions or shared service identities.

Key questions

Q: How should security teams limit the risk from AI agents that have access to production systems?

A: Security teams should scope every agent to the smallest set of actions and resources needed for its task, then remove standing privilege wherever possible. Use short-lived credentials, explicit approval for sensitive actions, and continuous review of what each identity can reach. The goal is to make compromise hard to turn into lateral movement or data exfiltration.

Q: Why do read-only AI agents still create serious security risk?

A: Read-only agents can still expose secrets, topology, environment variables, and other sensitive operational data. In practice, disclosure often creates the same downstream risk as modification because attackers can use the information for lateral movement, credential theft, or targeted follow-on attacks. Security teams should govern read-only access as a data-exposure path.

Q: What are the signs that AI agent permissions are too broad in enterprise environments?

A: Common warning signs include agents accessing tools they do not need, performing irreversible actions without confirmation, retrieving cross-tenant or unrelated data, and acting with long-lived credentials. If logs show the agent is using broad user permissions instead of scoped access, the control model is too loose and the environment is exposed to accidental or malicious misuse.

Q: What should teams do when an AI agent operates from an untrusted device?

A: Treat the device as part of the authorization decision, not a separate hygiene check. If the endpoint is unmanaged, unhealthy, or unexpected, the agent’s valid identity should not be enough to permit sensitive action or cloud access. Device trust should narrow where the agent can operate, not replace action-level authorization.

Technical breakdown

Authentication is not action approval

Authentication establishes that a credential, token, or certificate belongs to a recognised identity. Authorization determines what that identity may do at that moment. In an AI agent workflow, those two decisions must stay separate because the agent can remain properly authenticated while its prompt, retrieved context, or tool access leads it to take an unsafe action. The practical failure is treating login as proof of intent, when intent is not a stable property in agentic systems. That is why action-level authorization matters more than identity confirmation alone.

Practical implication: enforce per-action authorization so an authenticated agent cannot inherit every capability attached to its identity.

Prompt injection and excessive agency widen post-authentication risk

Prompt injection can arrive through emails, web pages, documents, code comments, or other retrieved content, then steer an agent toward unintended behaviour without breaking authentication. Excessive agency compounds the problem when the agent has more tools, permissions, or autonomy than the task requires. The danger is not just malicious input but also ambiguous instructions, poisoned memory, or failed integrations that redirect a legitimate workflow. The core issue is that valid identity does not guarantee valid decision-making once the agent starts reasoning across tools.

Practical implication: scope the agent’s tools, permissions, and autonomy to the minimum needed for the current task.

Zero Trust for AI agents requires continuous verification

Zero Trust assumes access is never permanently trusted after initial authentication. For AI agents, that means reassessing the user, agent instance, device posture, source of instruction, resource being accessed, and the current risk context as the workflow moves between applications. A token that looks valid on paper can still be unsafe if the endpoint is unmanaged, the instruction source is untrusted, or the action exceeds the approved task. Continuous verification is therefore a boundary-setting mechanism, not a one-time login event.

Practical implication: evaluate each request against current context, not just the original sign-in event.

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.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

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

Authentication failure is the wrong mental model for AI agents. The more precise problem is authority drift after successful login, where a valid identity begins to exercise capabilities that were never appropriate for the task. That drift is especially visible when agents inherit user permissions or shared service accounts, because the identity looks legitimate even when the action does not. Practitioners should treat intent validation as a separate control plane from identity proofing.

Excessive access is now an agent governance problem, not just an IAM problem. The article’s central warning is that AI systems can be authenticated and still unsafe if they are given read, write, send, delete, execute, and elevate capabilities in one bundle. That is a named concept worth tracking as post-authentication authority drift: the identity remains valid while the action surface exceeds the task boundary. The implication is that entitlement design must be tied to agent task scope, not to static identity labels.

Device trust and action trust have to be separated for autonomous workflows. A recognised agent running on an unmanaged endpoint is a different risk from the same agent on an approved device, but neither condition is sufficient on its own. NIST-CSF and Zero Trust thinking apply here because the security question changes as the workflow changes. Practitioners should assume the control failure is not access alone, but uncontrolled movement from authenticated session to unsafe action.

AI authentication must sit inside lifecycle governance for non-human identities. When agents use shared service identities or long-lived credentials, the governance assumption is that stable access is reviewable and durable. That assumption weakens when the same identity can be used across tools, contexts, and destinations in a single workflow. The result is a lifecycle problem as much as an access problem, and identity teams need to govern issuance, scope, and revocation as a continuous system rather than a one-time enrollment event.

Continuous verification is becoming the practical dividing line between secure and merely authenticated agents. The article points toward a field where identity confirmation is table stakes and policy enforcement does the real work. That shift aligns with OWASP-NHI, ZT-NIST-207, and agent-focused governance thinking because the question is no longer whether the agent can be identified. The real question is whether the organisation can keep constraining what it can do after identification.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Post-authentication authority drift: The real governance gap is not whether an AI agent can log in, but whether it keeps acting inside the scope that was approved. Once a task can branch into send, delete, execute, or elevate operations, the access model has to be expressed at the action level, not the identity level.

Authenticated agents force a closer link between NHI governance and Zero Trust architecture. Access review alone is too slow if the agent can change context mid-session, so practitioners need policy enforcement that reassesses source, device, destination, and requested action continuously.

For practitioners

• Define per-action authorization for agents Separate read, write, send, delete, execute, and elevate decisions so an authenticated agent only receives the exact capability needed for the current request.
• Restrict tool and autonomy scope Limit which tools the agent can call, which destinations it can reach, and how independently it can proceed when context changes mid-workflow.
• Verify the source of instructions Treat retrieved content, email text, webpages, and code comments as untrusted inputs until policy validates the instruction source and intended action.
• Add device checks before sensitive actions Require approved device posture for cloud and private resource access so a valid agent token cannot be reused from unmanaged or unexpected endpoints.
• Log the full decision path Record the user, agent instance, device, instruction source, tool calls, policy decisions, approvals, data access, and final outcome for review and containment.

Key takeaways

• Authenticated AI agents remain risky when identity proof is treated as equivalent to safe intent or safe action.
• The article’s core warning is that broad permissions, shared service identities, and prompt injection can all turn a valid session into unsafe behaviour.
• Practitioners should govern agents through per-action authorization, continuous verification, and device-aware access decisions rather than static login trust.

Key terms

• Object Level Authorization: Object level authorization controls access to individual records or resources, not just to an endpoint. It prevents users from reaching data that is technically available through a route but should remain hidden according to policy, role, or ownership. This is a key safeguard against broken access control.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Post-Authentication Authority Drift: Post-authentication authority drift is the condition where an identity remains valid while the actions it can take become broader than the task justified. In agentic systems, it describes the gap between successful authentication and the unsafe use of inherited permissions, autonomy, or tool access.
• Continuous Verification: A Zero Trust practice that re-evaluates trust during the session instead of relying on a single successful login. The control is stronger when context signals are available in real time and when the identity programme can act on those signals without creating excessive exceptions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.