Deploy AI agents without losing control

Learn in your browser · Chapter 01 of 06

A hypothetical failure makes the access and approval questions concrete. This walkthrough is fictional, not a verified report of an April 2026 incident.

Imagine a coding assistant asked to repair a test file. Its credential also permits deletion in a live database and in the backup account. In this fictional walkthrough it submits destructive requests to both, and neither service requires prior approval. The example assumes those requests succeed. No real company, date, agent or investigation is established by the references in this workbook.

This example does not assume malicious intent or establish what a real model intended. Errors, misunderstood instructions and hostile inputs can all lead to harmful requests. Review the access actually granted and the checks around consequential actions, regardless of the cause. The example illustrates risk; it does not prove that four controls prevent every failure.

Four planning questions guide this workbook: what access does the current task need, which actions are forbidden or approval-controlled, who approves an action above a defined threshold, and what evidence records the result? You can write the plans without code. Your administrator must check that credentials, tools and downstream services enforce the intended rules; a prompt or pinned note is not that enforcement.

• Q1: What happens in the fictional database-deletion walkthrough?
• A: A hypothetical test-file assistant also has destructive access to live data and backups. Both requests succeed without prior approval. This is a teaching scenario, not evidence of a real April 2026 incident.
• Q2: Does this walkthrough establish malicious intent?
• A: No. Intent is not established. Excessive permissions and missing approval checks can amplify harm from several causes, so inspect the actual controls without guessing intent.
• Q3: What are the four controls this workbook teaches?
• A: Least-privilege access, explicit forbidden and approval-controlled actions, a named human-approval threshold, and a checked log. Each rule needs appropriate implementation and verification.

Learn in your browser · Chapter 02 of 06

Most agent permissions are set once, for convenience, and never narrowed again. Least privilege means giving an agent exactly the access its current task needs, and taking that access away once the task is done.

Least privilege means granting only the access the current task requires and removing it when no longer needed. In the fictional walkthrough, repairing a test file does not justify destructive live-database or backup access. An engineer may need to separate credentials or tools when a vendor bundles permissions too broadly. Assess the real task and integration rather than treating every test-file job as identical.

Scroll sideways to see every column.

• Q1: What does least privilege actually mean for an agent?
• A: Giving an agent only the access its current task genuinely needs, and removing that access again once the task is done, rather than granting broad access once for convenience.
• Q2: Why is “just in case” access risky?
• A: Spare access can amplify an error. In the fictional walkthrough a test-file assistant can also reach live data and backups, even though that task does not justify that access.
• Q3: Should an agent's permissions start broad or narrow?
• A: Narrow. Add access only after establishing the task need and verifying its scope. The hypothetical deletion illustrates why broad unused access creates avoidable exposure, rather than predicting a certain outcome.

Learn in your browser · Chapter 03 of 06

Some actions are too consequential to leave to an agent's judgement, however good that judgement usually is. This chapter builds a short, specific list of exactly which ones, before you need it.

Separate three decisions. A complete prohibition means the agent may never perform the action, even if someone offers approval. An approval-controlled action is permitted only after the named person approves the exact proposed action. A routine permitted action may proceed inside its defined scope and threshold. A written list records these decisions; it must be implemented and checked at the tool or downstream service. Telling an agent "never delete" while leaving unrestricted deletion credentials available is not an enforced prohibition.

Make the category and action explicit. "This agent must never delete a contact's full history" is a complete prohibition. "A customer email must wait for a person to review and click send" is approval-controlled. "Be careful with customer data" specifies neither the action nor its enforcement.

• Q1: How is a never-without-a-person list different from a permission list?
• A: Permissions determine what a credential or tool can reach. The rules distinguish forbidden actions, actions requiring prior human approval and routine permitted actions. Check how the service enforces each rule rather than relying on the wording alone.
• Q2: Why does the never list need to be written down?
• A: Writing makes rules reviewable and transferable. It does not itself make them enforceable: an administrator must configure the boundary and verify that forbidden or unapproved requests are rejected.
• Q3: What makes a good never-without-a-person rule?
• A: State the exact action and category. For example, "history deletion is forbidden to this agent" or "customer sending requires a reviewed draft and a person clicking send". Name the enforcing control and test it.

Learn in your browser · Chapter 04 of 06

Not every action needs a person watching, and not every action can be left to run alone. A threshold decides which is which, before the agent ever has to choose.

A threshold specifies when a routine permitted action must wait for a named person's approval. A complete prohibition remains forbidden at every size; approval does not override it. Actions already designated approval-controlled still require prior approval below a numerical threshold. Use thresholds for the remaining permitted scope, and check the proposed action, recipient set or amount before execution, not after it.

Scroll sideways to see every column.

• Q1: What is a human-approval threshold?
• A: A defined line requiring a named person's approval before an otherwise permitted action proceeds. Separate complete prohibitions and actions that always need approval still apply.
• Q2: How is a threshold different from the never list?
• A: A complete prohibition blocks an action at every size and cannot be waived by this threshold. An approval-controlled action always needs prior approval. A threshold adds approval above a defined limit within the remaining permitted scope.
• Q3: Why must a threshold name an actual person, not just “someone”?
• A: An approval rule with no named, available person becomes either an unplanned delay or a rule people quietly bypass. Naming a real, reachable role is what makes the threshold work in practice.

Learn in your browser · Chapter 05 of 06

Access checks and approvals aim to prevent unauthorised actions. Logs support detection and investigation afterwards, within the evidence they actually capture.

Even a configured agent can encounter an unexpected condition. A checked log can help investigators establish which requests and actions occurred; it does not assure prevention or a complete reconstruction. In the hypothetical database walkthrough, missing records would make investigation harder. No claim about a real incident's logs is made here.

• What was asked of the agent, in the agent's own words or the request it received.
• What it actually did, in plain terms, not just "task completed".
• When it happened, with an exact time.
• Who, if anyone, approved it, when a threshold applied.

• Q1: What does a log actually protect against, if permissions and thresholds already exist?
• A: A checked log supports detection and investigation after an action. Its ability to reconstruct events depends on completeness, accuracy and integrity; it is not a preventive permission or approval check.
• Q2: Do I need special software to keep this kind of log?
• A: A spreadsheet can start the review process. Distinguish observed tool records from unverified manual recollections, control access and retention, and check what additional evidence consequential workflows need.
• Q3: What should a useful agent log actually record?
• A: Asked action, observed outcome, time and approval reference are four starter fields. They do not reconstruct almost any incident. Correlated identifiers, versions, trustworthy outcomes and protected records may also be needed.

Learn in your browser · Chapter 06 of 06

Use the four planning questions, check their implementation and test your understanding in the online knowledge assessment.

Return to the fictional walkthrough and ask four questions about your planned workflow. What can it reach and why? Which actions are forbidden or require prior approval? Who approves permitted actions above a defined threshold? What observed evidence records the outcome? Ask your administrator how the boundaries are configured and tested. These questions support a deployment review; they do not prove operational safety.

https://trust-agent.ai/exam/deploy-agents-without-losing-control

This is free educational content published by Mickai LTD, not professional, legal, financial or compliance advice, and Mickai accepts no liability for how you use it.

Human control and a visible record are useful design goals for Mickai workflows. Sovereignty is a question about the actual system: who controls access, which suppliers process data, where it is stored and which connections can transmit it. A label alone does not answer those questions.

Mickai can discuss bespoke agent workflows and code enhancements for a business at mickai.co.uk/bespoke. Agree the proposed access controls, hosting, suppliers, retention and permitted network connections, then examine implementation evidence and tests. This workbook does not establish zero data egress, sovereign operation or suitability for a particular customer deployment.