An agent can query the customer database, send emails and issue refunds. What is your security design?

What the interviewer is testing

Whether you understand that the model's instructions are not a security boundary.

The premise

Natural language instructions are not an access control mechanism. Indirect prompt injection — instructions embedded in a retrieved document, an email, a support ticket, a web page or a code comment — means the model can be induced to attempt any action available to it.

So the design assumption is: the model will attempt the worst action its tools permit, and the architecture must make that acceptable.

The design

Tools execute with the end user's identity and permissions, not the application's. An agent asked to read another customer's record fails at the data layer regardless of what convinced it to try. This is the single most important control and it is the one most often missing, because it is easier to give the agent a service account.

Scope each tool to the narrowest capability that satisfies its purpose. The database tool exposes specific parameterised queries, not arbitrary SQL. The email tool sends from a defined template set to the address on the account, not to an arbitrary recipient with arbitrary content.

Human confirmation for consequential and irreversible actions. Refunds, deletions, external communications and configuration changes require explicit approval showing the specific action and parameters, not a generic prompt. Approving "issue a refund" is meaningless; approving "refund £4,200 to account X" is a control.

Limits independent of the model: refund value caps, rate limits per user and per session, and anomaly detection on tool usage.

Full audit: every invocation with the user, the parameters, the result, and the context that prompted it.

The layering to state explicitly

Model-level defences — instructions, guardrails, injection detection — are probabilistic and can be worn down. They reduce the frequency of attempts. The permission model is what determines the outcome when they fail.

What a strong answer adds

Treating retrieved content as untrusted input crossing a trust boundary into a privileged execution context — the same category as user input reaching a SQL query — and separating instruction context from data context wherever the model interface supports it.

Common weak answers

Prompt instructions telling the model not to misuse tools. An input filter for injection attempts as the primary defence.