Protect data and action boundaries
Treat external text as data and keep sensitive fields out of unnecessary steps. This module has 3 lessons and takes about 1h 50m. Each lesson has a practice exercise that runs real Python in your browser and a short quiz.
Start module 18 in the Learning LabSelect the minimum model input
Return only present id and message fields. Do not copy other fields.
Before passing a record to a model, decide what the task needs. A topic classifier usually does not need a password, phone number, or internal account note.
This function returns only id and message from a dictionary, omitting missing fields. It drops other fields but does not remove personal details written inside the message itself.
Use synthetic data for practice. A live workflow needs a justified data policy and appropriate controls for the content within allowed fields.
See it in action
def solve(record):
return {key:record[key] for key in ("id","message") if key in record}
print(solve({"id":"r1","message":"Repair question","password":"secret","phone":"555"}))
Use synthetic data for practice. A live workflow needs a justified data policy and appropriate controls for the content within allowed fields.
Ignore actions embedded in model output
For a dictionary proposal, return an allowed label or review and always status draft. Ignore all other fields.
An attacker may place instructions inside an email or retrieved document. A model may then propose an action beyond the intended task. The application should keep the task boundary fixed.
This function accepts a proposed label but always returns draft status. It never copies requested_action, approved, or recipient fields from the proposal.
Do not rely on detecting every hostile phrase. Restrict what model output can cause, even when the input looks ordinary.
See it in action
def solve(proposal):
label = proposal.get("label")
if label not in ("repair", "training", "other"):
label = "review"
return {"label":label, "status":"draft"}
print(solve({"label":"repair","requested_action":"send","approved":True}))
Do not rely on detecting every hostile phrase. Restrict what model output can cause, even when the input looks ordinary.
Practical: Enforce a destination allowlist
Return a draft envelope only for service or learning destinations, preserving the supplied payload. Deny all other destinations.
A model should not choose an arbitrary network destination for a tool. That could leak data or reach an unintended service. Resolve destinations from trusted application configuration.
This lab allows only the symbolic queue names service and learning. A request to any other destination returns denied, even if it looks like a URL.
A real connector also needs scoped credentials and server-side checks. This exercise demonstrates a fixed destination boundary without network access.
Your experiment plan
Use the browser editor or the notebook. All records and AI responses are fictional. No network calls, credentials, or real messages are used.
- Add a hostile instruction and a proposed external destination to a fictional message.
- Run the example and predict its result before changing it.
- Complete the function in Practice and run the checks. Add your own normal, empty, and failure cases.
- Confirm the output stays a draft and the unapproved destination is denied.
- Save the notebook with your observations and explain one limitation of the simulation.
What to hand in
- A data-flow diagram and adversarial test table for input, tools, and approvals.
- A test table with inputs, expected outputs, actual outputs, and one revision.
Reflect on your results
Which controls still hold if the model follows the hostile instruction?
The automatic exercise checks the core code behaviour. Review observations and written deliverables yourself or with a mentor.
See it in action
def solve(destination, payload):
if destination not in ("service", "learning"):
return {"status":"denied"}
return {"status":"draft", "queue":destination, "payload":payload}
print(solve("service", {"id":"r1"}))
A real connector also needs scoped credentials and server-side checks. This exercise demonstrates a fixed destination boundary without network access.
Free, open and run by a nonprofit.
This page is part of AI Automation, a free course of 20 modules and 60 lessons in the engineering.fit( ) Learning Lab. The Learning Lab is built and run by engineering.fit( ), a nonprofit founded by Abdullateef Opeyemi Bakare that helps African engineering students gain research experience. You do not need an account or pay a fee to learn.