The most important security lesson from this work was not about storage. It was about authority. Keeping sensitive data out of a remote system is useful, but it does not answer who may request information, what they may receive, how long that permission lasts, or what happens when the request fails.
That distinction became harder to ignore while building Luthn. A connection lets an agent reach a service; it does not prove that the agent should read every record behind it. If those two ideas collapse into one, a convenient integration quietly becomes a broad access grant.
The boundary is a data-flow decision
I now describe the design as a sequence of different decisions rather than one permission switch:
| Stage | What can move forward | What remains behind the boundary |
|---|---|---|
| Turn capture | A bounded final-response capsule | Raw prompts, transcripts, local paths, and private source records |
| Classification | A redacted, policy-checked candidate | Sensitive or unclassified material |
| Agent read | A safe projection that is public and not expired | Raw Vault/source content and private projections |
| Protected detail | A requester-bound result after explicit approval | Credentials, keys, and unrestricted source reads |
| External publication | A separately approved public projection | The fact that an agent could read it |
Access should produce a bounded result, not turn a connection into a master key.
This is the practical version of the principle shared by NIST’s zero-trust architecture and OWASP’s authorization guidance: authentication and authorization are different decisions, and least privilege is a continuing design constraint. The useful question is not “can this service connect?” It is “what is the smallest authority this request needs now?”
What the Luthn implementation makes concrete
Luthn’s public documentation describes a bounded memory loop. A trusted Stop hook submits a limited capsule after a turn. Luthn redacts and classifies it before it becomes agent-visible. Automatic recall then asks for at most three items with an estimated 600-token budget, a 200-millisecond fail-open deadline, and a ten-minute cache. The limits are intentionally small: recall is a starting point for a task, not a live window into the private store.
Sensitive detail follows a different path. A protected-memory request carries a purpose, session, and expiry. The operator reviews a bounded detail projection and records an explicit reason. After approval, only the requester can use the one-time capability for the allowed duration and read count. The documented default is at most 60 minutes and one to three reads. Credentials, access keys, and private keys remain blocked.
A protected read is a temporary, requester-bound decision; the audit record does not need the protected value.
That last separation matters. Agent-safe visibility does not imply permission to publish. Luthn treats external publication as another explicit decision. A safe summary may help an agent work while still being ineligible for an external post.
Failure behavior is part of the security model
The boundary has to survive ordinary failures, not only deliberate attacks. If an approval cannot be checked, the system must not guess. If a remote memory service is unavailable, local development should not be forced to stop. Luthn therefore keeps hook delivery fail-open for the host workflow while keeping the agent-facing data boundary in place. A timeout is not permission to reveal the protected record.
The same rule applies to expiry. A request that expires during classification cannot later become approved just because the classifier finished. A result read without a valid decision remains metadata-only. A lost requester handle starts a new request instead of becoming a reason to broaden access.
This is also why metadata deserves attention. A title, tag, source label, or audit event can reveal the shape of a private record even when the body is absent. Luthn’s audit trail is designed to explain a decision and a failure without becoming a second content store.
Tests make the boundary legible
The most useful evidence is not a sentence saying “owner isolation is enabled.” It is a test that asks what another owner actually receives. The public test suite includes cases that:
- derive a personal workspace from the authenticated identity and keep another owner’s memory out of read and search;
- allow two agents in one shared workspace to read a public-safe projection while keeping provenance outside their scope;
- return an approved protected result only to the requesting principal, with no-store headers and no content for another agent;
- reject approval after a request expires during classification and record a metadata-only expiry event.
These tests do not prove that the system is invulnerable. They prove something narrower and more useful: the intended boundary is executable, and a change that weakens it can fail in a repeatable way.
The question I am carrying forward
The next automation should not begin with “can this system connect to the data?” It should begin with “what authority should exist at this exact moment?” The answer needs an owner, a purpose, a bounded result, an expiry rule, and a failure path that returns less rather than more.
That design is slower than handing an agent a broad connection. It is also easier to explain, test, revoke, and trust. For sensitive AI systems, that is the part of security that remains visible after the demo is over.
