A secure copilot, step by step

This is the capstone. A support copilot reads Maya's documents and acts for her. It needs every control in this track, working together. Your goal: follow one copilot from question to action, and see where each control sits.

Two powers, two risks

A useful copilot looks things up, and retrieval can show a document you should not see. It also does things, and a tool call can use more authority than you have. So check every read and every action against your permissions. One rule ties this lesson together: authorize the read, then govern the act.

Governed reading: filter every chunk

The copilot first retrieves passages from a knowledge base. That search does not know who you are. Asking the model politely not to leak is not enough. A clever prompt ("ignore your instructions…") can talk it into leaking. So the copilot runs a fine-grained authorization check on every retrieved chunk. It drops the denied chunks before the model writes anything. The model never receives text you cannot see. This is permission-aware retrieval built on relationship checks.

Whose access? Yours.

The copilot has no broad access of its own. It inherits exactly your document access, so its reach is never bigger than yours. This avoids the confused deputy. That is a program with wide privileges that an attacker tricks into working for them. Tie the copilot to your identity. Then every check asks "May this user do this?" and not "May the copilot?"

Governed acting: the same pipeline, plus a human

A tool call gets no private back door. It runs the same MCP governance pipeline as every agent, in this order:

1. An input guardrail on the arguments.
2. An on-behalf-of token exchange.
3. A scope check on the new token.
4. A relationship check for this tool.
5. For a write: a pause for a step-up approval.
6. The handler, the code that does the work.
7. An output guardrail that scrubs anything sensitive.

Reading a balance is low risk, so it just runs. Spending money is not. A write tool triggers an approval. The copilot stops and shows you the exact deal: "₹500 · 5 GB add-on · ref BUY-4821". Nothing is charged until you approve.

Delegation only narrows

Say the copilot needs your billing data. The lazy move reuses its own broad read-and-write token. A tricked copilot could then use that power to write. The safe way is delegation with narrowing. A second on-behalf-of exchange (RFC 8693) gives a dedicated billing agent a read-only token, with write removed. The billing agent still acts for you. But it can do only one narrow thing. Both hops are audited, so both agents show up in the agent registry.