Zero-Trust Physical Identity & The MCP Standard
A sovereign compute environment is only as secure as its physical access logs. The AI-Native Medical Office Building fuses cryptographic door strikes with BLE spatial positioning to achieve zero-trust physical identity. When the localized acoustic array captures an execution command, the orchestration layer cross-references the speaker's spatial coordinates against the physical security ledger. If no authenticated physical entry event exists for that presence, the packet is deterministically dropped — an agent's authority is bounded by who is verifiably in the room.
The physical building is abstracted into a standardized API endpoint through the Model Context Protocol (MCP). By wrapping the hardware sensor stack — uncompressed audio, spatial telemetry, physical door strikes, and local compute endpoints — into an MCP-compliant server, any authorized on-premise clinical model can query the room's physical state using native JSON-RPC tool calls, eliminating fragile custom middleware.
Exposing building hardware as callable tools to a language model creates an attack surface that the transport layer does not address. A model that ingests ambient clinical dialogue is ingesting untrusted input: a phrase spoken in the room, dictated from a patient's own document, or embedded in a scanned referral can attempt to redirect the agent toward an unauthorized tool call. Prompt injection, privilege escalation through chained tool invocations, and confused-deputy execution against the door-strike or record-retrieval interfaces are the governing risks, and none of them are mitigated by keeping the model on-premises. Locality contains where data goes; it says nothing about what the agent is permitted to do.
The specification therefore requires a Policy & Authorization Engine interposed between the model and the MCP server, so that no tool call reaches hardware on the model's authority alone. Every invocation is evaluated against externalized policy — Open Policy Agent or an equivalent deterministic decision engine — carrying the caller's authenticated identity, the physical presence evidence established at the door, the conformance class of the target tool, and the clinical context of the session. Transport between the agent, the policy engine, and the MCP server is mutually authenticated with mTLS and short-lived workload credentials. Authorization is fine-grained and default-deny: tools are enumerated explicitly per role, high-consequence tools require a corroborating physical-presence assertion, and the decision, its inputs, and its outcome are written to the local audit ledger before execution proceeds. Policy lives outside the model weights and outside the MCP server, which is what keeps it auditable by a reviewer and unreachable by an injected instruction.
Discovery is a separate and deliberately subordinate concern. Machine-level execution is carried by MCP over JSON-RPC and by the local REST endpoints, which are the primary system-level protocols and the only paths through which state changes. An optional llm.txt file placed at the local gateway (e.g. http://edge-node.local/llm.txt) serves as a human- and agent-readable documentation convention that indexes local GPU nodes, ceiling arrays, spatial grids, and room acoustic parameters. It is a directory, not infrastructure: it confers no authority, is never treated as a trusted source of policy or capability, and a conforming deployment operates fully without it.
To maintain deterministic execution during agent interactions, the local database replaces legacy JVM-bound graph databases such as Neo4j with the native C++ in-memory engine Memgraph. Operating the knowledge graph in C++ within volatile system memory eliminates Java garbage-collection pauses and enforces sub-millisecond execution boundaries for complex GraphRAG queries. Combined with ephemeral /dev/shm storage, intermediate transcription logs, video frames, and location metrics are released when the clinical session ends, minimizing the window in which raw encounter media exists in the system. Release of a volatile buffer is a strong reduction in exposure, not a cryptographic erasure proof: residual data may persist in DRAM until overwritten, and the design assumption is that the enclave's physical and access controls — not the volatility of RAM alone — protect the interval before reuse.
Requirements formalizing this section
The narrative above is non-normative. The clauses below state the same architecture as testable requirements, and a conformance claim is evaluated against them rather than against the prose.
- ANM-8.1MUST · Class A, B
A conforming deployment MUST treat entry to the enclave as an authentication event of equal standing to a software credential, and MUST record it as such.
- ANM-8.2MUST · Class A, B
A conforming deployment MUST bind each inference session to the physical identity or identities established as present in the enclave at the time the session is initiated.
- ANM-8.3MUST · Class A, B
Physical access records for a conforming deployment MUST be retained inside the demarcation boundary and MUST be subject to the prohibitions of Chapter 3.
- ANM-8.4MUST NOT · Class A, B
A conforming deployment MUST NOT permit administrative access to inference hardware, storage, or orchestration state from outside its demarcation boundary.
- ANM-8.5MUST · Class A, B
Maintenance performed by a software integrator MUST occur under an identity distinct from any tenant identity, and MUST be recorded with the same fidelity required of tenant access by ANM-8.1.
- ANM-8.6SHOULD · Class A
A conforming deployment SHOULD detect and record the presence of unenrolled individuals in the enclave during an active ambient capture session.
- ANM-8.7MUST · Class C
A Class C shell MUST document the physical access control provisions available at the intended enclave location, and MUST NOT claim identity binding, because no inference sessions exist to bind.