What should organisations do when AI tools can take actions on behalf of users?

Why This Matters for Security Teams

When AI tools can act on behalf of users, the security problem shifts from simple authentication to delegated execution. A user may approve a prompt, but the agent may chain tools, call APIs, read data, or trigger downstream workflows long after the original request. That means the real control point is not just who logged in, but what identity, privilege, and context were in force at the moment each action occurred. Current guidance in NIST Cybersecurity Framework 2.0 still applies, but agentic systems need stronger event-level traceability than a normal session log provides.

This is also where NHI governance intersects with AI governance. If the tool call is treated like a human keystroke, investigators lose the ability to distinguish operator intent from autonomous agent behaviour. NHIMG research on DeepSeek breach shows how quickly exposed AI-related assets can become a security problem once secrets and credentials are in play. In practice, many security teams encounter the failure only after an agent has already delegated access or copied sensitive data, rather than through intentional design.

How It Works in Practice

Organisations should treat agent actions as governed identity events and apply controls that bind each action to a specific workload identity, a specific user delegation, and a specific policy decision. That usually means combining RBAC for coarse access, intent-based authorisation for runtime decisions, and JIT credential issuance for the actual task. Static permissions alone are too blunt for autonomous systems because the agent’s exact path is not predictable in advance. The agent may begin with one approved goal, then select different tools depending on the context, the data returned, or the state of other services.

A practical implementation stack often includes short-lived tokens, policy-as-code, and detailed telemetry. The policy engine should evaluate the request at the moment of execution, not only at login, so the system can confirm the tool, target resource, data class, and allowed delegation chain. For agent identity, workload identity is the stronger primitive: the system needs cryptographic proof of what the agent is, not just a bearer secret. That is why implementations often borrow patterns from SPIFFE, OIDC, and zero trust design, with controls mapped to NIST Cybersecurity Framework 2.0 and AI governance principles in the NIST Cybersecurity Framework 2.0.

• Issue ephemeral credentials per task, not long-lived secrets for the whole agent lifecycle.
• Log the user, agent, tool, target system, policy decision, and delegation chain for every action.
• Revoke or expire credentials immediately after completion or when the task scope changes.
• Use separate identities for human approval, agent execution, and downstream automation.

NHIMG’s DeepSeek breach coverage reinforces the operational risk of exposed credentials in AI environments, while the broader secret-management findings in DeepSeek breach show why static secrets are a poor fit for autonomous workflows. These controls tend to break down when an agent can persist state across systems without a central policy checkpoint, because the delegation chain becomes fragmented across multiple services.

Common Variations and Edge Cases

Tighter delegated-access controls often increase latency and operational overhead, so organisations need to balance safety against workflow speed. That tradeoff is most visible in multi-agent pipelines, where one agent may call another agent, and each hop needs its own identity proof and authorisation decision. Best practice is evolving here, and there is no universal standard for every orchestration model yet.

For high-risk use cases, the safest pattern is zero standing privilege, with temporary access granted only after the system validates intent, context, and business justification. For lower-risk internal copilots, some teams keep broader read access but still enforce JIT credentials for write actions or external tool use. The important distinction is that autonomous behaviour cannot be governed as if it were a fixed user role. If the agent can decide when to act, the system must also decide when to stop it, based on runtime policy and full execution context. The NIST Cybersecurity Framework 2.0 helps structure that discipline, but agentic environments also benefit from emerging guidance in DeepSeek breach analyses, where exposure often starts with overbroad access and poor traceability.

In practice, the hardest edge case is a mixed human-agent workflow where the human approves a goal but not every downstream action. If the organisation cannot prove which step was human-approved and which step was agent-selected, the audit trail is incomplete by design.

Related resources from NHI Mgmt Group

• How do organisations distinguish human actions from automated AI tasks?
• Why do AI agents create more IAM risk than ordinary developer tools?
• When should organisations use AI to help manage NHIs?
• What is the difference between logging actions and logging intent for AI agents?