The safe answer to an unknown field is "no".
Every field carries a classification. Anything not explicitly declared visible is secret by default, so adding a new field can't quietly widen what an agent can see.
Published page
Contact status & email
Deal name & stage
Card details · PII · amounts
Unpublished drafts
The boundary — closed by default
Who is asking?
Every action runs as a specific user. No user bound to the run, and the agent sees nothing at all.
acting_as(principal)
Only what they may see
Records are filtered by exactly the same permissions a person has — owner, team, role. No new access is invented for agents.
visible_to()
Secrets become tokens
Sensitive values leave as reversible tokens the model never sees in the clear, and are restored on the way back.
token_vault()
Outside text is quarantined
Third-party content is wrapped as inert data, so a web page or an inbound email can't smuggle instructions to the model.
«untrusted-data»…
The agent, from outside
- Sees the fields its user may see
- Gets tokens standing in for personal data and identifiers
- Can propose changes for review
- Never sees other users' records
- Never sees raw secrets or unpublished drafts
- Can't publish on its own
Writes are proposals, not actions
The agent proposes a change
It's saved as a draft or staged change
A person — or a moderation workflow — reviews it
Only then does it go live
The worst an unattended or manipulated run can do is create an unpublished draft. It can't change what your customers see.
Every access leaves a trail
Append-only
Entries are added, never edited or deleted.
Hash-chained
Each entry seals the one before it.
Tamper-evident
Any change to the history is detectable.
You can answer "what did the AI see, what did it do, and on whose behalf?" — which is the question the whole sovereignty argument stands or falls on.
What we claim, and what we don't.
This is a design property, not a guarantee of invulnerability. What the architecture gives you is that the failure modes are bounded and visible: access is denied unless declared, sensitive values don't leave in the clear, an agent acts as a specific person rather than as the system, and every action is recorded in a log that can't be quietly rewritten.
It also means the interesting question — "should this AI be allowed to do that?" — is answered by your existing permission model rather than by a separate set of AI rules nobody maintains.
The in-editor assistant runs on this today. The headless side — scheduled and chat-driven agents — is built and covered by tests but not yet wired to a live transport in a deployment, and the Content Editor agent that drafts pages on its own is designed and not yet built. We'd rather tell you that than let you find out.
AI features are grounded in your own locally held data — never in a third party's memory of your business. If a feature would require sending business context somewhere it can't be governed or audited, we don't build it that way.
Ask us the hard questions.
Bring your security adviser. The boundary, the audit log and the failure modes are all things we're happy to walk through in detail.