Step-Up Authentication for LLM Agents Before Sensitive Actions

Why login-time authentication is not enough

A session authenticated at login shows who signed in. It does not show that the user approved a specific high-risk action minutes or hours later. Agents widen that gap because they hold standing credentials and can call tools that move money, change records, expose regulated data or alter infrastructure.

The model cannot be the party that decides when stronger assurance is needed. OWASP guidance says to treat model output as untrusted and to enforce permissions and parameter validation at the tool boundary. Screening for prompt injection does not stop an injection it fails to detect, or content that arrives through other channels. An approval gate at the tool boundary is a backstop that does not depend on detection.

Start by defining the sensitive set. OWASP names account recovery, payment initiation, privilege changes, bulk deletion and production deployment as actions that warrant step-up. For AI operations it adds model deployment, weight export, training data access and production configuration changes. Use these as a baseline, then add organization-specific risk thresholds. NIST's proposed agent identity tenets, which are an initial set and not a final standard as of October 2026, also call for organization-defined risk thresholds that initiate human review.

Classify on more than tool name. The same tool can be routine with one set of parameters and sensitive with another, for example a transfer below or above a limit, or a delete scoped to one record or to many. Express the classification as policy that evaluates tool, resource, operation type (read or write) and parameter values.

Binding the result, and handling denial and timeout

An approval is only meaningful if it covers the exact call that runs. Bind it to the tool, the normalized parameters (for example through a hash), the initiating user, the agent and session, a unique identifier and a short expiry. At execution, recompute the binding from the call actually being dispatched and compare. If the model changes a parameter after approval, the binding fails and the call is held again. Validate parameters at the boundary at execution time, not only when the challenge was issued.

Make approvals single-use. OWASP advises checking and consuming an approval in one atomic step so concurrent or repeated requests cannot reuse it. A check followed by a separate consume step leaves a window for replay.

Credentials matter as much as approvals. NIST's proposed tenets call for zero standing privilege, ephemeral access acquired when a task starts, and no long-lived bearer tokens or static reusable secrets. They also describe cryptographic linkage between an agent and the entity that initiated its task, with delegated scopes that attenuate downstream. Issuing a short-lived credential scoped to the approved action limits what a stale or over-scoped token can do.

Define denial and timeout explicitly. Both should block the call by default, return a clear result to the agent so it does not retry through another route, and be recorded. Choose approval expiry based on how quickly a real approver can respond and how fast the underlying context changes. Keep it short enough that a pending request does not outlive the situation that justified it.

Failure modes to test for

Test the flow as an attacker or a misled agent would use it. These cases recur in agent tool-use guidance.

• Replayed or reused approvals: Mitigate with single-use approvals, atomic check-and-consume, unique identifiers and short expiry.
• Stale sessions: Require re-validation for high-risk operations and a recent authentication event, not the login session.
• Bypass through alternate tools: Scope tools per agent, separating read-only from write and limiting resources. Give monitoring or reporting agents no write access to configuration or permission systems. Cover every MCP server in the same enforcement layer.
• Injection-triggered actions: Do not rely on detection alone. An agent acting on tool output with no review step lets a malicious payload cause real-world effects before anyone notices. Require explicit checkpoints for privileged or irreversible outcomes.
• Parameter swap after approval: Bind approval to normalized parameters and verify at dispatch.
• Delegation widening: Attenuate scopes for sub-agents so downstream entities cannot claim more authority than the parent.

Evidence the control must produce

A regulated enterprise needs to show an auditor that a sensitive action was authorized, not only that it occurred. For each intercepted call, retain the policy and version that triggered the requirement, the tool and parameters evaluated, the requirement set (authentication, approval, or both), who satisfied it and by what method, the time of challenge and response, the binding value, the decision, and what was ultimately permitted or blocked. Include denials and timeouts, since these show the control working. OWASP Cornucopia also calls for audit trails of approval for security-critical actions.

Store this as durable evidence generated by enforcement itself, so it is a by-product of the control and not reconstructed later. Under change management, treat agent, skill and MCP server configuration like code: version it, review it and approve it before deployment, and apply the same controls you would to human administrators.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. It can allow, redact, block, rate limit or escalate for human approval at the level of individual interactions and tool calls, and enforcement generates audit-ready evidence mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It can be self-managed in the customer cloud, with configurable retention and data residency. The design questions above apply whichever implementation you choose.