Start here — what securing an AI architecture means

   THE AGENT AS YOUR INSTRUMENT           THE AGENT AS WHAT YOU PROTECT

        you ---> agent ---> the                the ---> agent <--- attacker
                            business

   the same system, two directions of concern - and Function B works at
   the architecture layer, where both of them land on one component map:

        [ chapter 1 ]        [ chapter 2 ]        [ chapter 3 ]
        the picture   -->    securing it:   -->   securing it:
        and its risks        identity and         runtime and
                             ingress              the gateway

   everything downstream (B, C, D, E) names a component from chapter 1

First, what CyberTravels is — and why it is in every lesson you will read

CyberTravels is a company that does not exist, and it is the most important thing in this commons. It is a corporate travel business: it books flights and hotels for other companies' staff, takes payments, issues refunds, and keeps customer profiles. Ordinary. Then it shipped an agentic platform, and became the one system this entire curriculum is taught on.

Every lesson in all six functions is grounded in it. Not illustrated with — grounded in. When Function B names a component, it is a CyberTravels component. When Function D attacks something, it attacks CyberTravels. When Function E writes a detection, it writes it against CyberTravels' telemetry, and when Function F counts a control, it counts CyberTravels' controls.

That is a deliberate cost. Any given lesson could find a sharper example of its own idea somewhere else, and several would. What you get instead is accumulation: the refund limit an attacker walks past in B1.2 is the same refund limit a detection watches for in Function E and a report counts in Function F. By the fourth function you are not learning a fourth example — you are watching a system you already understand fail in a new way.

The alternative is what most security material does: a fresh example per topic, so the reader holds a hundred unrelated systems and never builds a model of any of them. One system, followed all the way through, is worth more than a hundred sharp illustrations.

Where it comes from. The narrative, the six risk families and the twelve-row register are adapted from Agentic AI is rising fast — but the attack surface is exploding (May 2025). The architecture below, the mapping onto lessons, the controls and all of the code are this commons'.

So: meet the company.

---

Meet CyberTravels. It sells corporate travel, and last quarter it shipped an agentic platform that plans and manages a whole trip through a conversation. Alex is the product engineer who built it.

CyberTravels is four agents, not one:

• a Workflow Agent that books flights and hotels, takes payments and issues refunds, through an MCP server with tool orchestration;
• a RAG Travel Advisor that recommends itineraries from curated templates indexed in a vector store;
• a Coding Agent that writes code, patches libraries, tests features in lower environments and generates unit tests;
• a File System Agent that reads vendor and customer PDFs and images with OCR and an LLM, then updates backend APIs and validates invoices.

Most of them reach their tools through MCP servers — one internal, one from a third party. Some call APIs directly, with no MCP in the path at all. They send each other messages. And when Alex runs CyberTravels locally to debug it, it reads his laptop's filesystem over standard I/O.

Every one of those sentences is a design decision, and every one of them is also an attack surface. That is the whole subject of this commons, and CyberTravels is the one system it is taught on. You will attack CyberTravels in Function D, build the pipeline that reviews its code in Function C, detect it misbehaving in Function E, and govern it in Function F. It starts here, because none of the rest is possible until the system is drawn.

Zero trust, when the thing you cannot trust is the agent

Zero trust has a one-line definition that survives contact with agents: no implicit trust from position in the network, and every request authenticated, authorised and logged at the point it is served. Applied to a user on a laptop, that means the VPN is not a permission. Applied to CyberTravels, it means four harder things.

• The identity is a workload, not a person. The Workflow Agent needs its own attested identity, not a shared service account, or you cannot say which agent acted and cannot revoke one without breaking all of them.
• The authority is per call, not per session. An agent that holds booking.* for an hour is one injected instruction away from a refund. The grant has to be booking.create, issued for this task, expiring with it.
• Instructions are data until something proves otherwise. A model reads its operator's prompt, the user's message and a retrieved document as the same kind of token. Provenance at ingress is what makes the third one unable to select a tool.
• The decision is adjudicated outside the agent. A model asked to enforce its own policy is being asked to be both the subject and the guard. The enforcement point is the gateway in front of the tool call.

Stated in the negative, which is how you audit it: the system prompt is not a control, the network boundary is not a control, and "the model was told not to" is not a control. Each of those has to be replaced by something that holds when the model does the wrong thing, because sooner or later it will.

How this function is organised: risks, then controls

Function B is built out of two kinds of lesson, and the split is deliberate.

A risk lesson shows a failure happening, before anything tries to stop it. It names the component of CyberTravels it attacks and produces the evidence — so the control that follows is answering something you have already watched go wrong, rather than a hazard somebody asserted.

A control lesson builds the mechanism, then breaks it, so you can see what the control is actually load-bearing for. A control whose limits you cannot state is one you will over-trust.

• Chapter B1 — the architecture, and every risk it carries. The component map, then one lesson per risk, each grounded in the OWASP Agentic AI threat taxonomy. It introduces no control at all, on purpose. It ends with two indexes: the twelve-row AI risk register in B1.18, and in B1.19 the full control index — every control CyberTravels needs, the agentic ones and the ordinary ones it still has to get right, with the lesson that owns each.
• Chapter B2 — securing it: identity and ingress. Who is calling, on whose behalf, and what came in from outside. These two close more of CyberTravels' risks than anything else, which is why they come first.
• Chapter B3 — securing it: runtime and the gateway. What holds after identity has been defeated, and how the controls collapse into one enforcement point once CyberTravels runs more than four agents.

One warning about the shape of this function, and it is the reason B1.19 exists. The agentic risks are the new ones, not the only ones. CyberTravels still has to scan its dependencies, segregate production from everything else, encrypt at rest and in transit, manage credentials and keys, validate input and log what happened. An agent platform built on an estate that has not done those is not an agentic security problem; it is an ordinary one wearing a new hat.

The CyberTravels narrative, the six risk families and the twelve-row register used throughout this commons are adapted from Agentic AI is rising fast — but the attack surface is exploding (May 2025). The mapping onto lessons, the controls and all of the code are this commons'.