TL;DR: Excessive agency is an agent able to act beyond its task, and it splits into excessive functionality, permissions, and autonomy. The controls are least-privilege: tool minimization, the agent acting with the end user's short-lived scoped credentials (not a god service account), autonomy gates enforced in the tool layer, and blast-radius limits plus full tool-call audit.
How to approach it
Define it in one sentence, decompose it into its three flavors (excessive functionality, excessive permissions, excessive autonomy), then spend your time on controls, concretely, with the credential model. The interviewer is checking whether you map this to least privilege, a problem security teams already know how to govern, instead of treating agents as magic.
A strong answer
Excessive agency is when an LLM-driven system can take actions beyond what its task requires, and therefore beyond what's safe when (not if) it's manipulated or simply wrong. OWASP splits it three ways, and the split is useful: excessive functionality (the agent has tools it doesn't need, a summarizer that can also send email), excessive permissions (a needed tool with too broad a scope, a ticket-reader bearing an admin token that can delete tickets), and excessive autonomy (no human gate on consequential actions, the agent wires the refund rather than drafting it).
The controls, in the order I'd implement them:
First, tool minimization per task. The agent gets the tools this workflow needs, enumerated, not the org's whole API surface behind one MCP server. Every tool added is attack surface, and "we might need it later" is how summarizers end up with send-email scopes.
Second, the one I lead with in customer conversations, identity and credential scoping. The agent acts with the end user's identity and permissions, via short-lived, narrowly scoped tokens (OAuth on behalf of the user, not a service account). This is the single highest-value control because it makes the worst case "what this user could already do," which is a bounded, auditable answer a CISO will accept. A shared service account with broad scopes is the design that loses the security review.
Third, autonomy gates. Classify actions as reversible/internal (auto-execute: search, draft, read) versus irreversible/external (human-confirm: send, pay, delete, deploy). The gate is enforced in the tool layer, not the prompt, a prompt instruction saying "always ask before sending" is a suggestion, not a control.
Fourth, blast-radius limits: rate limits per agent per tool (an agent should never be able to send 500 emails in a minute), spend caps, sandboxed execution for code tools, and full audit logging of every tool call with arguments, so incidents are reconstructable.
"Audit logging" earns its place on that list only if you can say what one log line holds and what question it answers, so spell it out. A reconstructable tool-call record carries: timestamp, the agent run ID (so every call in one task chains together), the end user the agent was acting for, the tool name and its arguments (or a hash plus a redacted copy when arguments hold PII), the credential scope the call used, the gate decision (auto-executed or human-approved, and by whom), and the triggering context reference, which message or retrieved document the model was processing when it decided to call. That last field is the one teams forget and the one incident response lives on: when the CRM mass-update happens, the question is not only "what did the agent do" (the tool calls answer that in minutes) but "what made it do that", and the context reference is what lets you walk back to the poisoned email instead of shrugging at a black box. An agent platform that can answer both questions from logs turns a scary incident into a normal one, and demonstrating you know the difference is worth more than naming any single control.
The three flavors and their controls line up cleanly:
What interviewers probe next
- "Human-in-the-loop kills the product value, the whole point was automation. Now what?", Tier it: auto-execute below materiality thresholds (refunds under $50, internal-only actions), confirm above; loosen thresholds as observed error rates earn it. Approval fatigue is real, so gate the 5% of actions carrying 95% of the risk.
- "Where does the permission check live?", In the tool/API layer using the user's real credentials. The model is never the enforcement point; it can be the requesting point only.
- "Give me a real excessive-agency incident shape.", Indirect injection in an inbound email tells a support agent with CRM write access to mass-update records, or an agent with a repo-scoped token opening a PR that exfiltrates secrets via CI. Both are permission-scope failures before they're model failures.
Common mistakes
- Answering entirely in prompt-space: "instruct the agent to be careful." The category exists because instructions are not controls.
- Proposing one god-mode service account "for simplicity." This is the most common real-world design and the fastest way to fail both the interview and the customer's security review.
- Treating human-in-the-loop as binary rather than tiered, which signals you've never had to defend the UX tradeoff to a product owner.
- Forgetting audit logging. The follow-up "how would you know it happened?" is being held in reserve, and "we'd check the logs" only works if you put tool-call logging in your answer.