TL;DR: Define the permitted effect of each tool, then enforce it with trusted identity, task authority and current resource policy. Limit the objects, recipients, amounts and lifetime as well as the tool name. Separate reading from writing where useful, but do not assume either a read or a reversible write is harmless. Preserve existing authorization for covered work.
How to approach it
Choose one workflow and make its authority explicit. In the fictional Alder workplace assistant, Priya asks for a ticket summary and a comment on one project document. She has broader access elsewhere, but this task does not need every document she can read or every action her account can perform.
A strong answer
Task grant
Owner, purpose and object scope
Tool proposal
Arguments are untrusted input
Backend policy
Current object and recipient checks
Observed result
Decision, effect and uncertainty
Trusted context supplies authority
The model selects arguments. Authenticated application state identifies the caller and grant; the resource service checks the actual object and effect.
Establish the caller and tenant from the authenticated session or trusted workload context. For a user task, the service checks both the user's applicable rights and the task's delegated scope. For a scheduled service job, use a grant with an accountable owner, purpose and permitted resources. A model-supplied user ID or a statement that a manager approved an action cannot replace this authority.
Use a permission worksheet rather than one broad “assistant” role:
| Tool | Scope for Priya's task | Enforcement at the backend |
|---|---|---|
| Search tickets | Named project, eligible fields and current reader access | Apply access policy before returning content; bound result volume |
| Read document | The selected document and needed sections | Check object access and source restrictions |
| Add comment | One document, permitted content and audience | Check write authority, current audience and notification effects |
| Create event | Not needed for this task | Do not grant it merely because the assistant supports it |
| Share document | Requires separate applicable sharing authority | Check recipient, classification and policy before changing access |
The tool contract should identify side effects. A comment may be deletable but already emailed to subscribers. An event invitation may expose attendees and meeting details. A search can disclose confidential data or consume expensive resources. Classify by information flow, affected people, cost and recovery limits as well as reversibility.
Purpose-built operations make these contracts easier to enforce. A general HTTP or query tool may be justified for some jobs, but needs explicit destination, credential, data and resource constraints. A typed argument establishes shape; the service still checks whether the selected object and recipient are allowed. Directory membership alone does not establish permission to receive a document.
Separate read and write capabilities so ordinary research does not automatically receive mutation authority. Keep credentials in the application or tool service when the model does not need them. Use intended audiences, bounded lifetimes and an explicit renewal policy. Short-lived credentials limit exposure time; they do not by themselves provide immediate revocation. The OWASP Authorization Cheat Sheet recommends least privilege, default denial and permission checks on each request.
Define when an action may proceed, needs a new decision or is unavailable. A covered comment can execute under a valid task grant and current policy. A new external recipient may exceed that grant. A prohibited disclosure stays prohibited even if the requester clicks approve; approval must come from an authority entitled to make that decision. Avoid asking again merely because the agent has taken another planning step.
For queued or long-running tasks, bind the operation to grant state and expiry. Recheck before the effect, propagate cancellation to workers, and specify the remaining race after dispatch. Revocation may also require invalidating cached authorization and blocking reuse of retained content. Do not promise that revoking a token retracts copies already sent to another party.
Record the actor, owner or user, grant version, operation, object, recipient, decision and outcome. Use restricted references to supporting evidence rather than logging every secret or document body. Include aggregate task and tenant limits so repeated permitted calls cannot silently exceed the intended budget.
Exercise: review three proposed permissions
Priya's task needs one comment on project document D7. Decide whether each proposal is sufficient:
- A credential can comment on all documents Priya can edit. It exceeds the required object scope unless another enforcement layer narrows D7.
- A D7-only tool checks the writer but not the current readers. It can still disclose restricted ticket details to the wrong audience.
- A D7-only tool checks writer, task, content-sharing policy and current audience. It can proceed when those conditions hold; another confirmation is not automatically required.
What interviewers probe next
- “What if the task genuinely needs deletion?” Define the authorized objects, aggregate bound and recovery behavior. Exclude deletion when unnecessary; do not claim it is universally forbidden.
- “Can the agent read everything the user can?” User rights are an upper constraint for this delegation, not a reason to retrieve every accessible record. Apply task purpose and data minimization too.
- “Where do tests run?” Exercise the backend with synthetic valid and invalid requests, including stale grants and changed audiences, without relying on the model to choose the invalid cases.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
Priya authorizes a summary of a project ticket and one comment on document D7. The assistant also supports calendar invitations and document sharing.
Start here
Should the task receive every tool Priya may use?
Separate account capability from task necessity.
No. Grant the operations and resources needed for this task. Priya’s broader rights may constrain what can be delegated, but they do not make every tool necessary. Calendar invitations and sharing require their own applicable task authority.
Carry it forwardTask scope can be narrower than account rights.
Weak answerTreating the user’s entire account as the default task grant.
Constraint changes
Is a comment safe to publish because it can be deleted?
Consider readers and notifications before removal.
No. Check whether the document’s current audience may receive the ticket information and whether publication triggers notifications. Removing the comment later cannot guarantee recall of delivered copies or what readers already learned.
Carry it forwardRecoverable storage is not recoverable disclosure.
Weak answerClassifying every editable write as low impact.
Constraint changes
What if Priya revokes the task while the comment is queued?
Identify the final check before publication.
Persist revocation and have queued workers and the publication boundary consult current grant state. Reject stale work before dispatch where possible, and report any already dispatched operation separately. A UI cancellation alone is not enforcement.
Carry it forwardRevocation must reach the execution path.
Weak answerAssuming a canceled screen means the worker stopped.
Now defend it
What should the permission review produce?
A tool-by-tool contract naming the principal, task grant, objects, recipients, limits and backend checks. Demonstrate one covered action succeeding and changes to audience, object and grant state being handled correctly.
How it's scored
These are site-authored practice criteria, not an employer's reported rubric.
Weak: Lists least privilege and confirmation without identifying the authority or enforcement point.
Hire: Specifies caller, task grant, object and recipient constraints and enforces them at the tools.
Strong Hire: Accounts for disclosure through reads and notifications, service-owned jobs, aggregate use, revocation and permitted work continuing under its existing grant.
Common mistakes
- Equating a deletable comment with a reversible disclosure.
- Using broad user access as the complete scope of every task.
- Checking permissions only when a tool is first added to the session.
- Assuming a confirmation can override organizational sharing policy.