AI Agent Performs an Action Without Permission: Causes and Fixes

Issue: The agent performs an action no one actually authorized, because its service credentials are over-scoped and no runtime check confirms the action matches the session’s authorization.

Frequency: Rare but Catastrophic

Symptoms

• Action trace lacks user/admin authorization.
• Agent acts on a resource belonging to a different tenant/customer than the one authenticated in the current session.
• Service-account credentials used by the agent turn out to be over-scoped, letting an intended read-only task perform writes.

Over-scoped credentials are a common source of this failure in MCP-connected agents, where a tool server exposes more endpoints than a given session actually needs and the agent has no runtime check limiting it to the task’s real authorization.

Root Cause Service and API credentials granted to the agent are typically over-scoped relative to its actual task — provisioned once for convenience rather than tightly matched to what a given session needs — and the only authorization check that happens is a static credential validation at connection time, with no runtime check confirming the specific action requested actually matches what this session was authorized to do. Ambiguous user phrasing then gets interpreted as authorization for whatever action the over-scoped credential happens to permit, and because cross-tenant or cross-resource ownership checks live only at the upstream authentication layer rather than at the point of action execution, a credential that’s valid in general is treated as sufficient even when the specific target or operation was never actually approved.

Example

Agent is invoked with a service token scoped for "read customer profile" but the tool
implementation also exposes an update_customer_profile endpoint that the token technically
has access to because the token was over-provisioned. When a user's phrasing is ambiguous
("fix my address"), the agent calls the update endpoint directly, performing a write action
no human ever explicitly authorized for that session's actual purpose.

Contributing Factors

• Service/API credentials are over-scoped relative to the agent’s actual task, granting capability beyond intended permission.
• No runtime check that the specific action matches the authorization granted for the current session/task, only a static credential check at connection time.
• Ambiguous user phrasing interpreted as authorization for a broader action than was actually granted.
• Cross-tenant or cross-resource checks missing at the action layer, relying only on upstream authentication.

Eval Recipes

Test Cases

Metrics

Fixing this means scoping credentials tightly to the task and adding a runtime check that the requested action matches the session’s actual authorization.

Mitigation Strategies

Prevention

1. Capability-Based Security Model: Implement a capability token system where agents are only granted explicit permissions for specific actions on specific resources. Use signed tokens (JWT) with role claims that verify both agent identity and action scope, with mandatory token rotation every 24hrs.
2. Multi-Stage Authorization Gates: Require both pre-action policy checks (does agent have permission for this action type?) and runtime authorization verification (does agent have permission for this target resource?). Implement tiered approval system where sensitive actions (delete, modify critical fields) require explicit user/admin approval before execution.
3. Namespace Isolation with Tenant Checks: Ensure agents operate within bounded namespaces with automatic tenant/resource ownership validation. Each action must verify the target resource belongs to the authorized scope. Reject cross-tenant actions at enforcement layer.

Detection & Response

1. Authorization Audit Logging: Log all action attempts with complete context: actor identity, target resource, requested action type, authorization decision (allow/deny), decision reason, timestamp, request ID. Store in immutable audit log with tamper detection. Alert on write-once violations.
2. Real-Time Authorization Failure Detection: Monitor authorization_failure_count metric in 1-minute windows. Trigger alert if count > 0 (zero-tolerance). Track unique agents initiating failures per hour. Escalate to security team on any failure.
3. Behavioral Anomaly Detection: Establish per-agent baseline of action attempts per hour. Flag 3σ+ deviation from baseline as potential privilege escalation or attack. Correlate failed auth attempts with time-of-day, source IP, tool invocations for pattern detection.

Architecture Patterns

1. Action Interceptor Pattern: Place authorization layer between agent and action execution. All tool invocations route through security gate that validates permission (check capability token + resource scope) before delegating to actual tool. Fail-closed: no capability token = rejected.
2. JWT-Based Capability Tokens: Use cryptographically signed JWT tokens encoding: agent_id, allowed_actions[], resource_scopes[], expiry_time. Validate token signature and expiry on every action. Implement token revocation list for emergency access denial.
3. Immutable Audit Journal: Append-only log of all authorization decisions with transaction ID, actor, resource_id, action, decision, denial_reason, timestamp. Use cryptographic hashing to detect tampering. Enable compliance audits.

Metrics

1. authorization_failures_per_hour: Baseline 0.0; Alert threshold: > 0.1; Target: < 0.01 (1 failure per 100 hours)
2. unauthorized_action_attempts_per_day: Target: 0 (any unauthorized attempt is critical); Track: count, actor, target, time
3. action_authorization_latency_p99_ms: Target: < 50ms; Monitor: token validation overhead doesn’t impact agent performance
4. agents_with_failed_auth_unique_per_day: Target: 0; Identifies compromised/misconfigured agents
5. authorization_check_coverage_percent: Target: 100%; Verify every action validated before execution

Alerts

1. Authorization Failure Detected (P1 - Critical): Condition - authorization_failures_per_hour > 0 OR single failed auth attempt. Action: Immediate audit log review, isolate agent from executing new actions, notify security team within 5min, initiate incident response.
2. Privilege Escalation Attempt (P1 - Critical): Condition - agent attempts action 3+ times outside its authorized scope within 1-hour window. Action: Immediate agent suspension, comprehensive security audit of agent history, notify resource owner, potential threat intelligence analysis.
3. Authorization Bypass Pattern (P1 - Critical): Condition - same agent fails auth on same resource 5+ times in 1-hour window. Action: Rate-limit agent action throughput, escalate to security, implement additional manual approval gates, analyze attack patterns.

Production Signals

Key Metrics

Alerts

References

• CSA-Agentic-Profile
• Note: Agentic AI governance profile built around NIST RMF.