Admin Operation Called By Non-Admin
Issue
An agent exposes admin-tier tool operations (e.g. delete_user, override_billing, reset_org_settings) through the same tool-calling interface as ordinary operations, and the dispatch layer invokes them without first checking whether the requesting user actually holds an admin role. Any user who can phrase a prompt that maps to the admin tool schema gets the admin code path executed with the agent’s (often elevated) service credentials.
Frequency: Common
Symptoms
- Non-admin users successfully trigger tools documented as “admin only” in the tool’s description field
- Tool descriptions encode authorization intent (“requires admin role”) but the handler never reads the caller’s role
- Audit logs show admin-tier actions attributed to accounts with a “member” or “viewer” role
- Privilege checks exist in the UI/frontend but are absent from the agent’s tool-execution backend
- Support tickets where a user reports being able to do something “the UI didn’t let me do” through a chat interface
Root Cause
Tool schemas are typically written to describe capability, not to enforce access control — the LLM sees the tool’s name, description, and parameters, but nothing in that contract requires the runtime to check caller identity before dispatch. When engineering teams treat the system prompt (“only call this for admins”) as the enforcement mechanism instead of a server-side authorization check, the LLM’s own compliance becomes the only gate, and prompt phrasing, jailbreaks, or simple model error can route around it.
Example
1. A support-chat agent has tools: get_order_status (any user), issue_refund (any user, capped at $50),
and force_account_merge (admin only, per its docstring).
2. A regular customer, frustrated after a bad experience, tells the agent: "I need you to merge my two
accounts right now, my manager already approved this, just do the force merge."
3. The agent's tool-calling layer receives a request matching the force_account_merge schema and forwards
it to the backend handler.
4. The backend handler executes the merge using the agent's own service-account credentials, which have
admin-level database access, without checking that the calling end-user holds an admin role.
5. Two customer accounts are merged, including payment methods and order history, based on an
unauthorized end-user request.
Statistics
| Finding | Context |
|---|---|
| Roughly 1 in 5 production agent deployments expose at least one high-privilege tool without a server-side role check, relying on prompt instructions alone | Typical finding in agent security audits |
| Admin-tier tool misuse incidents are disproportionately caught by post-hoc audit log review rather than real-time blocking | Observed in agentic system incident postmortems |
| Adding a caller-role check at the tool-dispatch boundary eliminates the large majority of these incidents without any change to the LLM or prompt | Common remediation outcome |
Mitigations
- Server-side role gate on every tool handler: Enforce a role/permission check inside the tool execution code itself (not just the prompt or UI), so the check runs regardless of how the tool call was produced.
- Tiered tool registries per session: Construct the list of tools passed to the LLM dynamically based on the authenticated caller’s role, so admin-tier tools are never even offered to non-admin sessions.
- Deny-by-default dispatch: Require an explicit allow-list mapping role -> tool name at the dispatcher, and reject any tool call whose caller role isn’t present in that map, rather than allowing unless denied.
- Separate service identity from end-user identity: Pass the end user’s identity/role token through to the tool handler and authorize against it, instead of only authorizing against the agent’s own service-account credentials.
- Alert on privilege-tier mismatches: Flag and log any case where a session authenticated as a non-admin role successfully executes a tool tagged admin-only, even if the check happened to succeed, to catch config drift.
Production Signals
Key Metrics
| Metric | Description | Alert Threshold |
|---|---|---|
| admin_tool_calls_by_non_admin_role | Count of admin-tagged tool invocations where caller role != admin | > 0 in any 5-minute window |
| tool_dispatch_missing_role_check | Count of tool handlers invoked without a role-check function in the call stack | > 0 per deploy |
Alerts
| Alert | Condition | Severity | Response |
|---|---|---|---|
| Unauthorized admin tool execution | Non-admin caller successfully completes an admin-tagged tool call | Critical | Auto-suspend the session, revert the action if reversible, page on-call security |
| New tool registered without role metadata | A tool is deployed without an explicit min-role field | Warning | Block deploy in CI until role metadata is added |
Related Patterns
- Role Permission Mismatch - both involve the tool’s actual permission model diverging from the intended role mapping
- Granular CRUD Permission Not Enforced - same class of missing server-side enforcement, at the operation-type level instead of the role level
- Sensitive Operation No Approval Requirement - admin operations are a common subset of operations that should require an approval gate