On this page
An AI assistant can be useful without seeing an entire personal archive. A coding assistant working on a repository may need the relevant issue, the last decision and a few document references. A meeting assistant may need different records. Sending the same full collection to both is neither necessary nor a reliable permission model.
Zortex separates three responsibilities: keeping the underlying records, assembling a useful slice for a request, and deciding which external application may receive it. Different AI tools can speak to that system through an interface rather than each maintaining an incompatible private copy of the user's history.
The gateway, policy and context code defines the retrieval and permission path shared by those integrations.
One gateway, two transports
The implemented gateway exposes Model Context Protocol (MCP) interfaces. Its MCP session handler provides a common tool and request path; clients can connect over process streams. A separate Streamable HTTP transport sends messages into the same session logic.
The HTTP transport is local by design. It refuses a routable bind address and normally listens on loopback. It also does not treat the self-reported name in an MCP initialize message as proof of the caller's identity. Instead, the launcher binds an application identity and issues a bearer credential for the local HTTP session.
This avoids a common mistake: making the transport an accidental permission bypass. If two transports reach separate business logic, small differences in result formatting or authorization tend to grow into different rules. Here the policy decision is meant to occur at the shared gateway boundary.
The implementation and its tests cover a defined subset of the MCP protocol. Providing the protocol surface is not the same as supporting every protocol feature or every host's extension.
A context request is not a database export
AI tool
|
v
stdio MCP / loopback HTTP MCP
|
v
Gateway: identify requesting app
|
v
Policy engine: active grant + scope
|
v
Scoped recall --> context assembly
| |
| v
+--------------> cited context slice
|
v
AI tool response
Out of scope / revoked --> typed refusal
One gateway applies source scope before assembling the context slice served to an AI.
An incoming request describes a task. A retrieval system can find candidate source records through text, semantic, graph or time-oriented access paths. But the request does not itself authorize reading every possible match.
The scope adapter wraps vault recall operations with the requesting app's authorized paths, event kinds and, where applicable, entity bounds. It applies that fence before the context engine combines candidates. Unauthorized material should not be recalled into a candidate pool and then merely hidden from the final answer.
This is a more useful boundary than a prompt saying, “Please ignore private information.” The system can refuse out-of-scope reads independently of the external model's willingness to follow instructions.
The resulting ContextSlice is a task-sized answer to the retrieval problem, not a permanent grant to browse the original vault.
Grants are states, not informal preferences
The policy engine tests demonstrate a grant lifecycle. A proposed grant is not active: requests made while it is pending are refused. User authorization moves it into an active state. Reads outside the allowed scope are rejected. Revocation makes the following verdict deny the request.
There is an important qualification in those tests: the implementation's default allowed content form is raw unless narrowed. We should not describe every connection as summary-only or imply the system automatically minimizes every permitted response. An app's actual grants and allowed forms matter.
The architecture has additional controls for application writes. The external-app path requires an application to be registered and granted appropriate scope, and stamps writes with a connector-attributed origin. An app cannot select a privileged user or system origin merely by putting that string in its request.
Read permission and write permission are separate safety questions even when an interface supports both. A useful context feature should not quietly imply authorization to modify the original record.
Keep provenance in the served result
Our context work goes beyond selecting a few convenient sentences. We need to be able to connect what an assistant saw to the source and version from which it came.
The component-context gateway works with typed component provenance and emits records for the served context slice and any loaded component material. It does not invent a component identity by parsing the user prompt. Its documented boundary can refuse the component-specific portion when required recording fails.
This distinction helps when a tool gives an answer based on context that later changes. A generic “the AI had your files” log is much less useful than a record of which references and versions were served under which application grant.
Once a permitted result is delivered to an external AI, that provider handles it under its own terms. Zortex governs the selection and handoff, not the destination's retention policy.
How we verify the interface
The gateway's MCP protocol tests exercise initialization, tool listing and typed refusals with an in-process JSON-RPC client. This is meaningful evidence for the internal wire contract.
The repository also includes a real-client evaluation designed to inspect Claude Code tool transcripts and gateway statistics. It is environment-gated: without the required machine-generated evidence it is skipped. Merely having that test in the tree is not proof that an external client was run for the latest candidate.
Similarly, configuring an AI host is not the same as verifying a useful authorized read in the installed host. Those are distinct checks.
Portability preserves access grants
Portability does not mean exporting a complete lifetime of private records to each AI. It means the owner can preserve one canonical context system and give an assistant bounded access to what a particular task needs.
The architecture gives us a concrete direction: different interfaces can reuse the same context assembly and policy decisions; each external application remains separately identifiable, grantable and revocable. The same scope and grant rules can be exercised across stdio and local HTTP transports. Each host's granted paths and content forms determine what it can receive.
Visual source: code-generated cover study.
