Security Boundaries Are Product Design
The actor asking for access should not control the approval channel
Why the Second Channel Matters
You enter a password on a laptop. A notification appears on your phone and asks whether it was you. The extra tap feels small, but the password alone can no longer approve the login.
The separation is not perfect. A determined attacker may still deceive the person holding the second factor. NIST does not describe out-of-band authentication as immune to phishing. The second channel still changes the attack because stealing one credential is no longer enough.
Most of us understand that arrangement without thinking much about it. A password opens the first door. A code or approval arrives somewhere else. The person has to be present in both places.
Then AI agents arrived, and software started forgetting the reason for the second door.
An agent may need permission to send a message or read a private record. The convenient design is to give the agent another tool called approve or unlock. When the user asks for the sensitive action, the model calls the tool and continues.
The workflow feels smooth because the request and approval happen in one conversation. That is also the weakness.
The model is the actor asking for access. If the model can call the approval tool, it controls both channels.
Instructions Share a Channel With Data
Prompt injection makes this problem different from an ordinary software bug.
An agent reads material while it works. That material may come from email or a web page. It may also come from source code, meeting notes, or files supplied by another person. The model receives both instructions and data as language. A hostile passage can therefore arrive disguised as part of the work.
The passage does not need to defeat the operating system. It does not need to break encryption. If the agent has a powerful tool, the passage can try to persuade the agent to use it.
OWASP calls one version of this problem excessive agency. The risk grows when a model receives more functions than its task requires. It also grows when those functions carry broad permissions or allow high-impact actions without independent review.
This is why security cannot depend on the model recognizing every bad instruction. Models will improve, filters will improve, and attack patterns will change. The product still has to decide which actions remain available when the model is wrong.
A prompt can tell the agent what it should do. A boundary determines what it can do.
That distinction changes product design.
The Missing Tool
The first question is usually about policy: when should the user allow this action? Agent-operated software needs another question: can the agent reach the action that changes the policy?
If an AI can call unlock, the name of the tool does not make it a security boundary. The same model that asks for access can grant access. A prompt-injection payload only has to steer the model toward a handle the product supplied.
The stronger design removes the approval action from the model’s tool surface.
The agent can still request access. It can explain why it needs the data and what it plans to do. The person approves somewhere else. The product then gives the running session a limited grant.
The absence of an unlock tool is a feature that can be tested.
We applied that rule while adding sensitivity controls to MOOTx01, a local memory system for AI tools. Ordinary recall excludes restricted and secret memories. The person can widen access for a limited time, but the MCP tool inventory contains no unlock command.
That absence is guarded by a test. If a future change adds any unlock-shaped verb to the AI tool list, the test fails before the release ships.
The approval path stays outside the conversation. On Apple platforms, the command uses the operating system to confirm local user presence. Linux and Windows use a secret supplied outside the AI tool channel. In both cases, the model may use an approved grant but cannot issue one.
Access That Forgets
Separating the approval channel solves only the first part of the problem. The product also has to decide how long approval remains useful.
A grant that survives forever becomes background state. Months later, nobody remembers why the door is open. A grant extended by every read can also remain alive indefinitely while an automated process keeps using it.
MOOTx01 treats the two sensitive tiers differently. Access to private material ends at the next local midnight. Access to secret material lasts thirty minutes from the approval moment. The secret window is fixed, so continued activity cannot extend it.
The grants live only in the resident service’s memory. Restarting the service locks both tiers. A person can also run the lock command at any time.
These rules make the promise concrete enough to test. One test approves a private grant and checks that access disappears at midnight. Another proves the secret grant ends after thirty minutes. Restart tests begin with new grant state and confirm that everything is locked again.
Audit completes the lifecycle. The log records when a grant was approved or denied. It records manual revocation and every sensitive read served under the grant. The record contains identifiers and times rather than the private content itself.
The result is deliberately temporary. The person authorizes a period of access rather than changing the permanent nature of the memory.
Name What the Boundary Protects
Security language becomes dangerous when the promise grows larger than the wall.
This boundary protects against an AI client that can call the memory tools but cannot act as the local user. It helps when a compromised prompt tries to widen recall through the MCP surface. It also prevents an ordinary agent mistake from turning into self-approved access.
It does not protect the estate file from a process already running with the user’s full local permissions. That process belongs to the operating system boundary. Under the current posture, sensitivity tiers control recall; they do not make secret rows unreadable on disk to the same local account.
This distinction matters because the user needs to know which wall carries which load. Application permissions cannot substitute for operating-system isolation. A local database cannot prevent recalled content from leaving through an AI conversation while still remaining useful to that AI.
The narrower promise can be tested and kept. A larger claim would create confidence where no boundary exists.
Useful Features Create Pressure
The difficult security choices usually involve features people value.
MOOTx01 can project memory into human-readable Markdown and import that material again. Portability lets a person inspect the data and move it between tools. The same path can move a great deal of information at once.
The current beta posture names that tradeoff. Vault tools are available by default and can be withheld during installation with --vault-off. Sensitive tiers remain excluded from ordinary bulk export. A future authorization gate is planned for more deliberate human approval around import and export.
That boundary is less complete than the sensitivity unlock boundary. Saying so matters.
Security design is not improved by describing tomorrow’s gate as if it protected today’s release. The current product has a coarse choice: expose the portability tools or remove them from the agent surface. A deployment that cannot accept the bulk path can choose the narrower surface.
This is what a real tradeoff looks like. Portability and risk come from the same capability. Product design decides where the control appears and what value disappears when the control is used.
The Human Decision Is Authority
AI is useful during this work because the surface is large. An agent can enumerate every model-callable tool and compare that list with the security policy. It can trace each code path that creates a grant. It can compare the Swift and Rust implementations and repeat the expiry tests.
The most valuable test may check for something that does not exist. The tool inventory must remain free of an unlock verb.
The human decision is about authority.
Which actions may the model initiate? Which actions require a person elsewhere? How long does that approval last? What event closes the door? What evidence remains after the action?
Experience recognizes that useful work often mixes trusted instructions with untrusted material. Perspective asks what happens when the model is persuaded rather than what the prompt intended. Imagination searches for the authorized handle that an agent might use correctly for the wrong purpose.
The machine can inspect the surface and iterate over the tests. The person has to decide where the surface ends.
Boundaries Are Product Design
The previous chapter dealt with installer authority on the user’s machine. This chapter moves the same responsibility inside the running product.
An installer needs permission to change the parts of a machine the product owns. An agent needs enough permission to do useful work. Security design decides which useful actions remain beyond the agent’s reach.
That decision changes the interface. It changes where the workflow pauses and how the person enters. It changes what a restart forgets and what the audit log remembers. It may remove a convenient tool entirely.
Those are product choices.
The practical test is direct. Name the actor and the action. Name the data and the approval channel. Then ask whether the actor requesting access can also control approval.
When both paths run through the model, there is one channel wearing two labels.
A real boundary gives the person a separate door.
Off-Axis Labs: All the science, fewer casualties.
Source Notes
MOOTx01 maintainers, “ADR-025: Sensitivity Unlock: Grants, TTLs, and the Out-of-Band Approval Seam,”
docs/decisions/ADR-025-sensitivity-unlock-policy.md.MOOTx01 maintainers,
packages/kits/AriaMcpKit/Tests/AriaMCPTests/ToolProjectionTests.swift.MOOTx01 maintainers,
packages/kits/AriaMcpKit/Sources/AriaMCP/SensitivityGrantLedger.swiftand Rust mirror.MOOTx01 maintainers, “Security Policy,”
SECURITY.md.MOOTx01 maintainers, “ADR-015: Vault Security Posture,”
docs/decisions/ADR-015-vault-security-posture.md.OWASP Gen AI Security Project, “LLM01:2025 Prompt Injection” and “LLM06:2025 Excessive Agency”.
National Institute of Standards and Technology, Digital Identity Guidelines: Authentication and Authenticator Management, NIST SP 800-63B-4.
MOOTx01 git history for sensitivity grants, out-of-band unlock, audit verbs, redaction, and tool-projection guards through
4b394617.