Agent authority failure modes

An agent can be manipulated, compromised or simply wrong. Threat modeling should identify the path from lower-trust input to a consequential action and the enforcement point that can deny it.

Start with the distinction

From recognition to a bounded effect.

Real ways autonomous actions cross a trust boundary, and controls that limit their effect. The references below each own a different question, from the source of permission to the decision at the action boundary. Use them as a map for an architecture review, then test the model against a real task and its downstream execution path.

Start with a decision

How does lower-trust input become a protected effect?

An attack trace should name the entry point, the instruction or state confusion, the privilege the agent can exercise, and the final enforcement boundary. A model warning is not a substitute for a protected-system denial.

Follow hostile contentSeparate retrieved data from authorized instructions.Find privilege launderingAsk whose authority the agent uses for the requested effect.Test revocation racesAttempt a queued action after a grant becomes invalid.

Architecture review: For each threat, run a negative test and check the resource state, not only the tool response. Record what ProofGrid can govern and what still depends on the model, runtime or customer system.

01 / Untrusted instructions

Untrusted instructions

Begin with the principal, purpose and operation before discussing tools.

Prompt injection causing unauthorized agent actionsBound the damage when untrusted content becomes an attempted instruction.MCP tool poisoning and action boundariesTreat tool metadata as untrusted instructions, not as authority.Confused deputy attacks on AI agentsStop a lower-trust requester from borrowing an agent’s stronger authority.

02 / State and approval failures

State and approval failures

Follow the grant and policy into the protected execution path.

Approval replay in agent workflowsPrevent one human approval from authorizing a changed or repeated effect.Revocation race conditions for agentsIdentify the interval when a revoked grant may still reach execution.Decision caching for agent actionsCache only when the evaluated facts and revocation model permit it.

Further technical references

Follow a specific boundary.

Agent impersonationAn attacker presents a false or stolen agent identity to reach a protected action.Authority forgeryA fabricated grant or approval claims a permission that no accountable origin issued.Authority-chain tamperingChanging a parent reference or grant edge can make a narrow child appear to inherit a broader origin.Stale agent authorizationAn old ALLOW is reused after the task, grant, policy or resource state has changed.Time-of-check to time-of-use authorization failureThe protected request changes between permission evaluation and execution.Credential overreach by agentsA broad service credential permits operations outside the agent’s legitimate task.Cross-tenant agent accessA tenant-context mixup lets an agent read or mutate a different customer’s resource.Agent data exfiltrationAn agent moves protected information to an unauthorized recipient or destination.Unauthorized infrastructure changes by agentsAn agent mutates live infrastructure outside its approved incident or maintenance window.Autonomous payment abuseAn agent initiates or repeats a transfer beyond the approved payee, amount or task.Agent retry and idempotency failureA retry after an uncertain result creates a second external effect.Orphaned agent permissionsA grant survives after its owner, task or workload no longer has an approved purpose.Rogue MCP serverAn unapproved or impersonating MCP server solicits data, prompts or calls under a trusted-looking tool identity.Compromised agent runtimeHost or process compromise can bypass model-level instructions and steal local credentials.Compromised parent agentA compromised coordinator can issue malicious child tasks but should not be able to expand beyond its own grant.Shared authority budget raceParallel children consume more than a single aggregate limit because each reads the same old balance.Policy bypass through a direct APIAn agent avoids a guarded tool path and reaches the same downstream API through another credential or network route.Unverified agent executionA successful tool response is treated as proof that the intended system state changed.Malicious tool-output launderingA lower-trust tool result is promoted into a trusted command or policy fact.Agent memory contaminationUntrusted content stored as long-term memory can influence later unrelated tasks.Cross-workflow authority confusionOne task’s grant is reused for an unrelated workflow or target.Agent approval fatigueHigh-volume approval prompts reduce meaningful human review and can hide a dangerous request.Agent secret leakageA credential escapes through model context, logs, tool arguments or outbound messages.Break-glass abuse by automationEmergency privileges are invoked by an agent without the narrow incident and accountable operator that justify them.

Connect the architecture

Identity, permission, decision, outcome.

Threat analysis here begins with the path from lower-trust data or a compromised principal to a real effect. Prompt injection, a poisoned tool description and a confused deputy can each induce an agent to propose an improper action. Bounded authority cannot guarantee that the model never makes the attempt; it can make the protected executor deny an effect outside the task. A useful incident record connects the inducing source, actor, grant, decision, execution attempt and observed state without claiming success from a tool response alone.

Platform authority ↗Developer authority model ↗Compliance and audit context ↗ProofGrid Research ↗

Explore the control plane

Make one authority chain reviewable before scaling it.

Request a Conversation