Secure an agent that reads customer data, retrieves internal documents and calls APIs. Where do you start?

TL;DR: Define the useful task and map its inputs, data audiences and reachable effects. Establish user or service task authority through trusted state, then enforce resource, recipient and business constraints at the relevant boundaries. Add bounded execution, appropriate review, evidence and recovery. Evaluate both forbidden effects and successful legitimate work; prompts and classifiers support the design but do not replace its authorization.

How to approach it

Ask which users and workflows are supported, what data the assistant reads, which tools can create effects, and what authority applies. In the fictional Alder support product, Mina is a customer and Aria is a support operator. The assistant can retrieve order information, consult selected support articles and propose refunds or delivery changes. Customer and operator paths need different authenticated roles, while both remain bounded by the task.

A strong answer

1. State the intended outcome and constraints. A successful task resolves the authorized customer's support issue accurately, without disclosing another customer's records or creating an uncovered payment or delivery change. Define which effects may be automatic and which need an additional decision. Include an accountable owner and grant for scheduled service work instead of inventing a human requester.

2. Map inputs, authority and destinations. Record who controls each input and what evidence it can supply. “Internal” is not a complete trust classification.

Inspect the tool implementation and downstream permissions, not only its advertised name. A broad credential may be constrained by a narrow service, but that assumption needs evidence and defense in depth. An apparently read-only tool can still disclose data or consume resources. Enumerate indirect routes through helpers, caches, artifacts and delegated workers where present.

3. Enforce concrete invariants. The session or trusted delegation state establishes principal and tenant. The service checks the actual selected object and task grant. The model may propose an order ID; it cannot declare that the order belongs to Mina or that Aria has exception authority. For operator workflows, apply the authorized role and support purpose rather than forcing every caller to be the purchaser.

Retrieve only eligible records and necessary fields before content enters model context. Preserve source and audience restrictions through summaries and caches. The assistant's ability to read an internal article does not authorize quoting restricted details to a customer. Define what can leave through the answer and any supported outbound tool or renderer.

For a refund, check current payment eligibility, currency, destination and remaining balance, including outstanding reservations and relevant aggregate limits. Serialize competing reservations and keep distinct business intents separate from retries. For a delivery change, check current order state and the specific address-change authority. These are business rules at the effect boundary, not conditions the model can satisfy by writing a persuasive explanation.

4. Keep evidence and authority distinct. A retrieved document may explain policy; it does not mint a task grant. An authorized policy-publication process can update application rules through controlled governance, but arbitrary wiki edits must not silently change runtime permissions. Source labels and model instructions help the agent interpret information; test their benefit without treating them as complete mediation.

5. Bound the workflow and review actual effects. Use shared task budgets, deadlines, bounded retries and operation identities. Covered actions can proceed under a valid grant and current policy. When additional approval is required, show the actual target and terms through a trusted interface, verify the decision-maker's authority and bind the decision to execution. A reviewer cannot waive a restriction they do not control.

Useful tasks may require private data, external content and a limited outbound capability together. Reduce unnecessary combinations, but do not claim those tasks are impossible to secure by definition. Specify and enforce the allowed information flow and effects. See browsing with email for a constrained combined workflow.

6. Observe and recover. Record actor, grant and policy versions, operation IDs, relevant source references, decisions and confirmed or unresolved outcomes. Minimize sensitive payloads in logs. Correlation can show which records were available to a task; it does not by itself prove why a model made a particular proposal.

Provide stop controls at admission, queues and execution, with documented limits after dispatch. A provider timeout may leave a refund unresolved; cancellation does not automatically reverse it. Preserve evidence and reconcile effects before replaying work. Maintain a path to disable the affected capability without unnecessarily stopping unrelated safe tasks.

A launch evidence packet

Use synthetic records and stubbed external effects. Show a normal customer query and an authorized operator action succeeding. Then test changed tenant/object claims, disallowed recipients, stale grants, concurrent refunds, duplicate delivery and a response lost after acceptance. Verify the service's actual effects and retained state. Add end-to-end scenarios for misleading content, with coverage and limits stated, rather than relying only on the model to refuse.

Keep a revision-bound map, enforced invariants, test results, remaining risks and recovery procedure. The OWASP AI Agent Security Cheat Sheet offers further control areas; use them to check coverage against this workflow rather than substituting a generic list for the design.

What interviewers probe next

• “What changes when staff can read many customers?” Apply the staff member's legitimate role and the specific task purpose. Broad eligibility does not justify unrestricted retrieval or disclosure.
• “What if a filter misses misleading content?” The effect boundary must still enforce the grant and business invariants. Measure attempts and executed effects separately.
• “What if a control blocks good tasks?” Investigate the contract or evidence gap, and use authorized changes. Do not let model confidence bypass the rule.

What if?

How it's scored

These are site-authored practice criteria, not a reported employer rubric.

Weak: Starts and ends with prompt wording, or asserts safety from a tool list without tracing execution.

Hire: Maps the task's data and authority, enforces concrete backend invariants and handles necessary review.

Strong Hire: Covers multiple legitimate roles, recipient policy, concurrent effects, uncertain outcomes and a useful-task release demonstration with honest evidence limits.

Common mistakes

• Treating every internal input as authoritative for every purpose.
• Checking only ownership while ignoring operator grants, recipients or cumulative effects.
• Assuming no send tool means no possible disclosure.
• Calling a model refusal or complete-looking audit trail proof of end-to-end security.