What breaks when an agent can call tools without user context?

Why This Matters for Security Teams

When an agent can call tools without user context, the security model stops being tied to a person and becomes tied to a workload that acts on its own. That breaks per-user filtering, shared-session assumptions, and audit trails that only say “the agent did it.” Security teams lose the ability to answer a basic question: who was this action actually for, and under what approval boundary?

This is especially important because autonomous systems can chain tool calls, revisit prior outputs, and keep acting after the initiating prompt is gone. Guidance from OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point to the same operational issue: once an agent is allowed to act independently, static identity and permission models become too coarse. NHI Mgmt Group’s Ultimate Guide to NHIs also shows why this matters, including the finding that 97% of NHIs carry excessive privileges.

In practice, many security teams encounter overbroad access only after the agent has already exposed data or triggered an action that was never meant for the current user.

How It Works in Practice

The core failure is that the agent becomes the only visible actor, while the original user intent disappears. If the system cannot carry user context into every downstream tool request, then policy decisions become detached from the business purpose of the action. That creates hidden overprovisioning, weak attribution, and broad access paths that look legitimate because they were initiated by an authorised agent.

Current best practice is to bind tool use to workload identity plus runtime context, not to a shared agent account. That means using cryptographic workload identity, short-lived credentials, and policy evaluation at request time. Frameworks such as CSA MAESTRO agentic AI threat modeling framework and NIST AI Risk Management Framework both support this direction, even though there is no universal standard for agent context propagation yet.

• Issue per-task, short-lived credentials rather than durable secrets.
• Pass user intent, tenant, and purpose into policy checks for each tool call.
• Log both the agent workload identity and the initiating user context.
• Restrict high-risk tools to just-in-time approval or explicit reauthorization.

This is where workload identity standards and policy engines matter. In practice, teams often combine SPIFFE-style workload identity, OIDC-backed tokens, and policy-as-code so the system can decide whether the agent may act right now, for this user, in this context. These controls tend to break down when a single agent serves many tenants and the application cannot reliably propagate the initiating user’s context across each downstream hop.

Common Variations and Edge Cases

Tighter context binding often increases implementation overhead, requiring organisations to balance stronger isolation against latency, integration cost, and operational complexity. That tradeoff is real, especially in multi-agent systems where one agent hands work to another and the original user context may be partial or ambiguous.

In some environments, the right answer is not full per-user delegation but a constrained service policy with explicit task boundaries. Best practice is evolving here: some teams preserve end-user context only for sensitive actions, while others propagate it through every hop for complete auditability. Either approach is safer than collapsing all requests into one shared agent identity.

Two patterns deserve special attention. First, tools that return broad datasets can accidentally bypass tenant separation if the agent is treated as a trusted intermediary. Second, actions that look harmless in isolation, such as search or enrichment, can become privilege escalation paths when the agent can chain them without fresh approval. NHI Mgmt Group’s research on the OWASP NHI Top 10 and the AI LLM hijack breach shows how quickly this turns into lateral movement when tool access is not continuously re-evaluated.

Where this guidance breaks down most often is in legacy applications that cannot carry user context through asynchronous jobs, background queues, or federated SaaS integrations.

Related resources from NHI Mgmt Group

• What breaks when every agent in a team can call the same tools?
• Why do collaboration tools create such a large secrets risk?
• Why is single-provider AI agent governance not enough for enterprise security?
• Why do application testing tools matter for NHI governance?