Separate the identities in the transaction
Record the human requester, the agent workload and the downstream service identity. If every tool call appears as a shared service account, responders cannot tell who initiated the action or which agent policy applied.
Bind the user’s permitted scope to the agent session. The agent should not gain access simply because its backend can technically reach the system.
- Unique workload identity per agent or service
- Delegated user context where appropriate
- Short-lived credentials
- Clear ownership for non-human identities
Put policy between reasoning and execution
The model may propose an action; a deterministic policy layer decides whether it may execute. Check the requested operation, target, data classification, amount, time, environment and requester.
Design tools with narrow verbs such as read invoice or create draft, not a generic execute-anything interface. Smaller tools are easier to authorize, test and monitor.
- Allowlist tools and parameters
- Apply transaction and rate limits
- Block production changes from test agents
- Require human approval for irreversible actions
Make approval meaningful
A confirmation button is weak if the reviewer cannot see the proposed effect. Show the target, changed fields, data leaving the boundary and a clear summary of consequences.
Avoid approval fatigue. Low-risk, reversible actions can be auto-approved within policy; high-impact actions need a person with the right authority, not whichever user is online.
- Preview the exact action
- Use separation of duties for sensitive changes
- Expire pending approvals
- Preserve the approval record
Design for containment and investigation
Provide a fast way to suspend one agent, one tool or one tenant without shutting down every AI feature. Log policy decisions and downstream receipts so the team can reconstruct what happened.
Test compromised-agent scenarios during tabletop exercises. Ask how keys are revoked, queued actions are stopped and affected records are identified.
- Per-agent kill switch
- Tool-call correlation IDs
- Tamper-resistant audit trail
- Recovery and correction workflow
A practical 30-day field plan
Week one — Request. User identity, intent and context. Put one accountable owner in the room, agree which business service or decision is in scope, and record the assumptions the team is making. Resist the urge to begin with a technology purchase; the first deliverable is a shared view of the problem and the authority to change it.
Week two — Policy. Risk, device, data and action checks. Walk through the current process with the people who operate it. Compare the written design with real access paths, data flows, exceptions and on-call practice. Mark every point where an owner is missing or where the team cannot produce evidence that a control works.
Week three — Approval. Automatic limit or human confirmation. Choose a narrow pilot that can be observed safely. Define the expected result, the rollback path and the person who may accept a trade-off. Capture operational friction as product feedback; controls that are difficult to use will eventually be bypassed.
Week four — Execute. Scoped tool call, receipt and monitoring. Review the pilot with engineering, operations, security and the service owner. Close urgent gaps, assign longer work to a funded backlog and set the next evidence review. The month should end with a repeatable operating rhythm, not a one-time presentation.
Evidence worth keeping
Good evidence is understandable outside the team that created it. Keep a concise record that connects the decision, owner, technical implementation and observed result. Screenshots can support evidence, but configuration, logs, test output and approved records are stronger because another person can reproduce or challenge them.
- Unique workload identity per agent or service — owner, current state, last validation and any open exception
- Allowlist tools and parameters — owner, current state, last validation and any open exception
- Preview the exact action — owner, current state, last validation and any open exception
- Per-agent kill switch — owner, current state, last validation and any open exception
- Decision log showing who approved residual risk and when it will be reviewed
- Test or exercise result with the actual outcome, not only a pass label
Questions for the leadership review
Use these questions to keep the discussion connected to operating risk rather than tool activity. A useful answer names a person, a service and evidence.
- Who is accountable for the agent security outcome when teams disagree about delivery and risk?
- Which critical service or customer promise would be affected by a failure in this area?
- What evidence would tell us the design is working in production today?
- Which exception creates the largest concentration of access, dependency or recovery risk?
- What would the team contain first, and how would it restore a trustworthy service?
- Which improvement can be completed in the next 30 days without waiting for a large programme?
Common questions
Should an agent use the same permissions as its user?
Usually no. It should receive only the delegated scope required for the specific task and duration.
Is human approval always required?
No. Use it for consequential or ambiguous actions; enforce low-risk actions through deterministic policy and limits.