The first question a security team asks is never about the model. It is about the data. What can this thing read? What can it change? Where does our data leave a place we control? So we stopped explaining it in prose and started handing them a map.
What the diagram is actually claiming.
Every box on the left is a system the customer owns. The dashed line is the trust boundary — the point where data would leave the customer's control. The map exists to make one claim provable: nothing crosses that line unless the diagram says it does.
- Read-only means the agent holds a credential that cannot mutate state. Not "we promise not to write." The credential literally cannot.
- Read · write is the narrowest possible scope. The agent can append to the ticket queue. It cannot delete, cannot read other tenants, cannot escalate.
- Never touched means no credential was ever minted. Payments and PII are not behind a guardrail the agent could argue its way past. There is no key on the ring.
A trust boundary you can draw is a trust boundary you can audit. If it only lives in a config file, it does not exist yet.
Why read-only is a credential, not a rule.
The most common mistake we see is treating access scope as policy — a document that says the AI "should not" write to production. Policy is advice. A scoped credential is physics. When security asks us to prove read-only, we do not show them the policy. We show them that the token issued to the agent has no write grant, and we show them the audit log proving no write was ever attempted.
The line that does the work.
The orange dash is the only thing on this page that matters to a regulator. Everything to the left is the customer's. Everything that crosses must be named, scoped, and logged. We would rather hand over a diagram that admits a write than a paragraph that hides one.
— Suhail Abidi. Los Angeles, May 2026.
Comments