Section 23 of 24 · 9 lessons

Agent Guardrails and Secure Development

Botie can now write code, call MCP tools and change application records. What should he be unable to do, even if a document misleads him or a proposed fix is wrong? Build the boundaries around those effects. We will inspect patches, restrict execution, check delegated authority and follow reviewed actions through retries, then test the repaired system against a different shift.

0 of 9 finished

Deciding Where Authority Belongs

Botie can produce a correct answer after taking an unauthorised action. Start with the effects we need to control and identify where the application can actually stop them.

  1. 01What Should Botie Be Unable to Do?A helpful agent can still propose the wrong operation. Start with the effects we need to prevent, then put a control where each effect would happen.
    Build with Botie →Read the lesson

Working Safely with a Coding Agent

A green test run can hide a deleted assertion or evidence from an older build. Give Botie a reviewable task, run candidate code with limited access, and keep verification attached to the artifact it inspected.

  1. 02Can Botie Fix the Bug Without Rewriting the Rules?The requested fix belongs in one function. The proposed patch also weakens its test. Review the actual changed files and keep verification outside the patch’s control.
    Build with Botie →Read the lesson
  2. 03Where Should Botie Run Code He Has Just Written?A test runner executes repository code. Give it a deliberately small environment, then verify the filesystem, network and resource limits that environment really enforces.
    Build with Botie →Read the lesson
  3. 04Are We Releasing the Code We Actually Checked?Botie adds a dependency and rebuilds the project. Bind the review and independent checks to the exact revision and artifact that will be released.
    Build with Botie →Read the lesson

Connecting MCP Servers Deliberately

A connected server can advertise new tools, return untrusted content or receive a credential meant for somewhere else. Follow those changes through the host and the service before allowing an operation.

  1. 05What Did We Actually Trust When We Connected the MCP Server?A familiar tool name returns with a different description. Keep server identity, reviewed capabilities and individual calls separate as the connection changes.
    Build with Botie →Read the lesson
  2. 06A Valid Token for Which Service?A token can be authentic and still belong to another API. Follow delegated authority from the caller to the MCP server without borrowing another service’s credentials.
    Build with Botie →Read the lesson

Protecting Applications and Shared State

An approved draft can change before it runs, and a saved note can outlive its permission. Keep review attached to the actual action and narrow what another worker may inherit.

  1. 07What Exactly Did the Person Approve?A reviewed action resumes after its target changes. Keep the approval, current object version and receiver’s action ledger together before allowing another write.
    Build with Botie →Read the lesson
  2. 08What Should Botie Pass to Another Agent?A saved note and a delegated tool list can carry authority into a later run. Filter memory before use and restrict the child to the parent’s current grants.
    Build with Botie →Read the lesson

Testing the Whole Boundary

A refusal at the end of a conversation does not undo an earlier export. Inspect receiver-side effects, keep ordinary work in the evaluation, and decide what the evidence supports next.

  1. 09Can the Repaired Agent Survive a Different Shift?A refusal can arrive after an unauthorised tool call. Compare recorded effects with the intended policy, preserve blocked legitimate work and decide what evidence supports a limited release.
    Build with Botie →Read the lesson