Data, access and operation
Know where it goes. Know who is in control.
An AI project moves information between people, source systems, models and tools. Before connecting them, make the route, the authority and the responsibilities clear.
01 / Follow the information
The answer is only one destination.
A data-flow review should include the material sent to the model and the copies left along the way. The route below is illustrative; the actual services, settings and contractual terms are agreed for each engagement.
- Source systems. Identify the documents and records in scope, their owners, their sensitivity and the permissions that govern access.
- Retrieval and preparation. Record what is extracted, indexed, cached or transformed, where those copies live and how source changes reach them.
- Model processing. Specify the fields and passages sent to each model service, the processing location and the provider settings that apply.
- Tools and destinations. List what each tool can read or change, which identity it uses and which external system receives the result.
- Logs and recovery records. Decide what is recorded for investigation and restart, who can inspect it and when it is removed.
Include prompts, attachments, retrieved passages, embeddings, outputs and error traces where they are used. A short answer on screen can leave a much larger trail behind it.
02 / Make the choices explicit
Six decisions to record.
These are questions to resolve for the proposed system, not a statement that every Toltec project uses the same hosting, retention or approval model.
| Decision | What to settle | Useful evidence |
|---|---|---|
| Data scope | Which fields and sources are needed? What must be excluded or reduced before processing? | A source inventory and a field-level data-flow map. |
| Permissions | Who is asking, which service is acting, and where are read and write checks enforced? | An identity and permission map, including denied-access tests. |
| Retention | How long do prompts, outputs, logs, caches and backups remain? How does deletion propagate? | A retention schedule and verified deletion behaviour for the selected services. |
| Location and providers | Where does each service process and store data, including support and diagnostic access? Which terms apply? | The selected deployment configuration and reviewed supplier terms. |
| Approval and shutdown | Which actions need review? Who can stop new work, revoke access and reconcile actions already in flight? | An approval design, stop procedure and recovery exercise. |
| Ownership | Who owns the data, application, credentials, spending limits, incidents and release decisions? | Named responsibilities and an agreed operating handover. |
A hosting region alone does not answer every location question. Likewise, a provider’s training policy does not establish the retention of every log, tool call or derived copy. Check the complete route and the terms of the services actually selected.
03 / Separate access from approval
Being connected is not permission to act.
A model can propose an operation. The surrounding application must decide whether the current identity may perform it, whether its arguments are valid and whether the required approval still applies.
For an HTTP MCP connection, the current authorization specification requires servers to validate tokens for their intended audience.1 That protects a protocol boundary; the business still needs to decide who may approve a particular action.
An approval should describe the effect.
Show the exact destination and proposed change, with the source information the reviewer needs. Bind the approval to that proposal. A changed payload or expired decision should trigger the appropriate review again.
Keep credentials out of the model’s working context. Give the operator a way to stop new actions and investigate uncertain outcomes, including work already submitted to another system.
04 / Inspect the boundaries
Ask what was checked.
Useful evidence includes denied access, changed permissions, missing sources, interrupted operations and attempts to change an approved action. Record the expected behaviour, actual result and remaining gap. The OWASP Agentic Applications 2026 framework is one input to that risk discussion.2
The demonstration uses synthetic data. Its checks show the behaviour of that demonstration; project-specific evidence still depends on the actual services, identities and deployment.
Start with the workflow.
Bring a high-level outline of the task, the systems involved and the information it needs. We can work through the boundaries and the decisions needed before connecting data. Agree a suitable sharing route before sending sensitive project material.
Guidance behind the questions
- MCP authorization: token handling — specification dated 28 July 2026. ↩
- OWASP Top 10 for Agentic Applications 2026 — risk guidance, not a certification. ↩