01 · Executive summary
The scarce resource is not AI code. It is deployable trust.
AI makes useful software faster to create, but most regulated organizations still move each new application through a bespoke sequence of identity, network, data, security, and evidence reviews. The result is a growing inventory of prototypes and a narrow production channel.
Janus Stack is designed to widen that channel by making the application’s trust contract durable and machine-checkable. Code can change language, runtime, model, or cloud. The stable application identity, approved service dependencies, operating boundary, release evidence, and accountable owner remain connected.
The architecture combines four controls that are usually fragmented across gateways, service meshes, secrets systems, deployment tools, and AI-agent frameworks:
- Application grants authorize exact service operations only when the workload credential, declared manifest, root-owned policy, current attachment, and authenticated route agree.
- Formal policy verification proves safety properties over canonical policy spaces, produces counterexamples when conditions fail, and binds the resulting proof fingerprint to signed Cedar-style policy records.
- Hardware-backed node authentication adds fresh device-held proof to the node-bound API key so a copied credential is insufficient to join a protected branch.
- Agent intent identity binds a single tool call to the agent instance, task, target, tool version, input digest, deadline, approval, and one-use assertion—then carries that assertion digest through every federation hop.
This is not a claim of automatic regulatory compliance. It is an architecture for turning policy intent into bounded runtime decisions and reviewable evidence, reducing the amount of custom trust plumbing required for every new AI application.
02 · The deployment problem
Regulated enterprises need more production paths, not more exceptions.
Healthcare and finance cannot treat every AI prototype as a trusted internal service simply because an employee created it or a cloud account hosts it. The application may touch protected health information, non-public financial data, payment systems, customer communications, model providers, or operational tools. Each connection carries a distinct purpose and accountability requirement.
Traditional platform controls often begin with a network location or workload certificate and infer the rest. AI raises the stakes of that assumption. An agent can change the sequence of actions at runtime, a model can propose an unexpected tool call, and a useful experiment can rapidly become a departmental dependency. A static “inside the mesh” identity is too broad to explain why a particular action was allowed.
Janus starts with a narrower question: what is the smallest authority this exact actor needs for this exact action? The answer is assembled from independent facts—stable identity, declared dependency, signed policy, authenticated placement, current health, task context, and time bound. A missing fact is a denial rather than an invitation to fall back to ambient trust.
Standardize the evidence and decision path once, then let teams deploy many different AI applications through it without forcing those applications into one language, model, cloud, or proprietary runtime.
03 · Identity model
Five identities form one attributable decision chain.
Janus separates identities that conventional infrastructure frequently collapses. This preserves accountability when applications move and prevents an agent, application, or node credential from silently inheriting another role.
Each boundary authenticates its direct peer. Credentials never confer transitive trust, and a relay may forward only along its validated branch.
| Identity | Stable anchor | Rotating context | What it cannot become |
|---|---|---|---|
| Node | Persistent UUID and direct-parent enrollment | Session, node-bound API key, hardware challenge | An application or agent credential |
| Application | Stable application UUID and approved origin | Process instance UUID and short-lived session | A federation peer |
| Agent | Approved agent identity and owner | Agent instance, task, plan, admission window | A general node administrator |
| Tool call | Versioned tool contract | Input digest, target, deadline, one-use assertion | An arbitrary shell or open-ended capability |
| Policy | Authority node and policy family | Canonical revision, proof fingerprint, signature | A container for raw secrets |
04 · Application grants
An application receives the intersection, never the union, of authority.
Every application is a leaf attached to one Janus node. It does not implement federation, accept federation children, or receive a transitive node credential. A stable application UUID persists across rewrites and moves; each running process receives a new instance UUID so operations can distinguish the application from one execution of it.
The default application credential covers lifecycle operations such as connect, heartbeat, durable logging, typed control polling, and explicit-proxy egress. Mesh-service operations are never implied. They must be named individually, such as a read operation against an object store or a validation operation against central identity.
The bearer or approved short-lived session is bound to the stable application UUID. A claimed identity mismatch fails before service routing.
The registered manifest names the service, protocol version, and exact operation. Wildcards are rejected.
The root-owned policy grants an exact scope to the inventoried application at its approved origin node.
Stale identities, detached policies, mismatched origins, unknown operations, and forged descendant routes fail closed.
Providers advertise named and versioned capabilities without revealing backend addresses or credentials. Applications call only their attached node. The invocation follows the authenticated tree to the selected provider and retains the application and origin identities. This makes a provider replaceable without distributing its connection details throughout application code.
Why this speeds regulated deployment
A security reviewer can reason about the stable application record instead of every framework-specific implementation. A rewrite from Python to Rust or a move from private cloud to a managed platform does not erase the owner, approved service list, network boundary, or evidence history. The new implementation must still register the same declared contract and pass the current release path.
05 · Policy formal verification
Policy is compiled, proved, signed, and activated as a controlled artifact.
Janus uses a restricted Cedar-style policy language for five business-policy families: application egress, application service access, node service access, operator capabilities, and agent controls. The language keeps Cedar’s principal–action–resource–context model, implicit deny, and forbid-overrides behavior while using a deliberately bounded grammar that Janus can parse into a typed abstract syntax tree.
Janus Policy Calculus (JPC) is the verification layer beneath that policy. It compiles an immutable snapshot into canonical sets over application identity, authenticated origin, hostname language, destination ports, service scopes, and federation route predicates. It then proves registered invariants using deterministic Rust set algebra—without an LLM, external inference service, or sampling process.
| Proof obligation | Meaning | Failure evidence |
|---|---|---|
| Grant containment | Every approved service grant is contained by the application’s declared dependency set. | The exact scope in grants ∖ requested |
| Attachment totality | An application cannot be authorized without an attached, enabled root policy and fresh identity. | The missing or detached application policy |
| Origin equality | The application’s policy origin matches its authenticated inventory route. | The expected and observed node identities |
| Destination bounds | Sensitive clients do not receive an unbounded hostname universe. | A symbolic hostname witness |
| Port bounds | Reachable destinations do not silently imply every TCP port. | A port-space witness |
| Route coverage | The request route matches the topology certified by the authenticated inventory path. | The first mismatched hop or unsupported runtime gap |
For each policy record, Janus canonicalizes the source and AST, computes a SHA-256 digest, records the JPC proof fingerprint, and signs the digest with the member’s Ed25519 policy key. The root verifies the signature, authority identity, certificate, revision, and coverage before presenting the record as current.
The policy engine was designed for reversible migration. Shadow mode compares the new engine with an earlier authority, canary mode permits selected policy families to become authoritative with explicit safeguards, and enforce mode uses the signed bundle. Certified production builds now support a retired legacy-source state in which all five families are authoritative, fallback is disabled, and startup fails if the signed identity-bound bundle is absent or invalid. Append-only rollback snapshots remain available to the separately controlled release process.
JPC proves the registered invariants over the snapshot and model it receives. It does not prove that every external runtime forces traffic through Janus, that DNS can never change, or that firmware boot state is measured. These remain explicit model gaps or separate attestation obligations rather than hidden assumptions.
06 · Node identity
A protected node must possess the enrolled device key, not merely copy a credential.
Janus federation is a rooted tree. Each child authenticates only to its direct parent using TLS, a persistent node UUID, a node-bound API key, required protocol scopes, and—when enrolled—fresh hardware proof. Primary data-plane and independent priority-control sessions authenticate separately.
The implemented hardware provider on macOS creates a non-exportable P-256 key in the Secure Enclave for each direct parent. During authentication, the child offers the public key and provider. A supporting parent returns a fresh 256-bit nonce and a challenge that expires after 30 seconds. The signed transcript binds:
- challenge identity and nonce;
- parent and child node UUIDs;
- the enrolled API-key identity;
- primary or priority-control connection role;
- challenge expiration; and
- the SHA-256 fingerprint of the offered hardware key.
The parent records a successful proof as pending until an infrastructure administrator verifies and accepts its fingerprint. Acceptance creates an immutable hardware requirement for that node’s API-key enrollment and terminates both sessions. Every reconnect must then present the accepted key and fresh proof. There is no downgrade to API-key-only authentication. Rotation requires revoking the enrollment, issuing a new API key, and approving a new hardware identity.
This is device-held federation authentication, not a compound platform attestation. The hardware key does not currently prove firmware measurements, the complete boot chain, a VM image, the active policy digest, or the running executable in one statement. Janus’s separate verified-release watchdog supplies content-addressed release validation, sustained health proof, and rollback.
07 · Provider roadmap
One node-proof contract, multiple non-exportable key providers.
The node authentication transcript is intentionally provider-neutral at the protocol boundary. The roadmap is to preserve the node UUID, direct-parent binding, challenge freshness, API-key binding, role separation, and operator-approved fingerprint while replacing the local signing backend to match the deployment environment.
| Provider class | Planned role | Required controls before certification |
|---|---|---|
| Cloud HSM / managed key service | Hold a non-exportable asymmetric node key and sign the canonical Janus challenge from a cloud workload. | Customer-controlled key policy, workload identity, tenant and region binding, request audit, bounded latency, fail-closed outage behavior, and explicit key generation. |
| Hardware HSM appliance | Expose a signing slot through a constrained local broker, commonly through PKCS#11 or a reviewed vendor interface. | Protected local IPC, slot and mechanism pinning, operator separation, backup/rotation ceremony, tamper response, audit export, and prevention of generic signing. |
| Edge trust module | Use a TPM, Secure Enclave class, or equivalent device key for constrained nodes. | Device provisioning, anti-cloning proof, key non-exportability, lifecycle recovery, physical replacement procedure, and optional measured-state evidence. |
Remote cloud signing and local hardware signing have different failure and latency characteristics, so Janus should not hide them behind an unqualified “HSM enabled” flag. The provider record must identify algorithm, key generation, attestation class, proof freshness, and verification policy. A policy can then require the appropriate class for a regulated branch without changing application manifests.
A later compound attestation can bind measured boot or VM image evidence, the running Janus release digest, active policy-bundle revision, and hardware key. That is roadmap work and should be introduced as a new certified evidence contract rather than inferred from possession of a signing key.
08 · Agent identity plan
An AI agent needs identity for intent, not a reusable pass to the network.
janus-hsm is the staged identity and approval service for agent-originated calls. Its current Phase 8 boundary is deliberately static: an AES-256-GCM software vault holds per-identity Ed25519 keys; every assertion requires an explicit review and fresh one-use software touch; assertions are short-lived and context-bound; and only deterministic in-memory ls@1 and ps@1 fixtures can execute. No live model, VM, host process, shell, passkey, or hardware HSM is represented as certified.
The assertion schema binds the identity and request to a source node, target node, target service, agent instance, task, optional control plan, exact tool and version, input digest, purpose digest, idempotency key, deadline, issuance time, and expiry. Janus pins the provider’s public trust bundle, verifies the assertion, consumes its unique ID once, matches the complete call context, and binds the assertion digest into every short-lived Agent RPC hop grant.
Why the assertion digest travels with the call
Janus Agent RPC allows a registered agent to address its local node and certified descendants, never a parent or sibling branch. Each relay verifies the grant from its direct parent, consumes exactly one route element, and issues a new short-lived grant. Binding the HSM assertion digest into every grant makes the reviewed intent part of the routed request rather than an unverifiable event that happened earlier in another system.
Path to a live production agent
The repository’s production-agent plan blocks live admission until deterministic gates certify identity lifecycle, signed intent, revocation, VM isolation, a typed tool broker, prompt and content isolation, default-deny egress, data-loss controls, external audit anchoring, kill paths, recovery, shadow evaluation, and an independently reviewed attended canary.
The intended first production boundary is one named agent instance in one dedicated VM, on one branch, with versioned read-only semantic tools, no direct shell or network access, a fresh approval for every call, and an independently authenticated kill path. Expansion to writes, unattended approvals, multiple agents, delegation, or broader data is a new security phase—not a configuration toggle.
09 · AI-native mesh
A services mesh made from the ground up for AI.
Conventional service meshes are optimized for stable services communicating inside one orchestration domain. Janus is built around a different unit of trust: a customer-owned application or agent crossing clouds, private infrastructure, and edge environments while retaining a stable governance record.
Workload connectivity
- Identity often follows a pod, service account, or namespace.
- Policy primarily authorizes service-to-service network paths.
- Endpoints and sidecars live inside one cluster or control plane.
- Human review, agent intent, and tool schemas sit outside the mesh.
Identity-bound capability use
- Stable node, application, agent, task, and call identities remain distinct.
- Policy authorizes exact operations, declared dependencies, and branch routes.
- Providers advertise capabilities without distributing backend addresses or credentials.
- Approval, proof, release, route, deadline, and audit context travel with the decision.
Janus nodes can host applications, provide or consume services, relay approved calls, and aggregate evidence. The rooted topology makes every trust boundary explicit: a child has one parent, each hop validates its direct peer, branch-local providers can supersede an inherited provider, and applications never become transitive peers.
This creates an AI services mesh in which identity and purpose are control-plane primitives. A model provider, clinical data adapter, policy engine, secrets broker, object store, audit service, or release controller is exposed as a named capability with an exact operation contract. The application receives the result it is authorized to use—not a permanent backend credential.
10 · Industry deployment paths
Map the same trust primitives to different regulated workloads.
Clinical summarization assistant
The application keeps a stable identity and declares only patient-context read, approved model inference, and audit-write operations. Root policy binds it to the clinical branch and denies every unrequested service. A named agent may propose a read-only summarization tool call, but the call carries task, patient-context classification, purpose, input digest, deadline, and approval evidence. The model never receives the data service credential.
Exception review agent
The application declares read-only access to a bounded transaction view and case-management write access for one structured outcome. Policy proves the grants remain within the manifest, the node proves its enrolled identity, and each agent call is branch-local, time-bound, replay-resistant, and attributable. Promotion from recommendation to transaction-changing authority requires a separate policy and certification phase.
For both industries, the value is the reusable path: application registration, exact service grant, policy proof, signed revision, verified release, node proof, agent assertion, service invocation, and audit evidence. The organization can map these artifacts into its HIPAA, HITRUST, PCI DSS, FFIEC, SOC 2, model-risk, or internal control program without claiming that the architecture itself supplies certification.
Policies and audit records can retain identities, decisions, digests, tool versions, routes, timing, and typed errors without storing raw prompts, private keys, bearer credentials, or unrestricted regulated content.
11 · Deployment sequence
Scale by certifying a path, then repeating it.
- Define the durable application record. Assign the stable UUID, owner, purpose, data class, attached branch, service dependencies, egress needs, recovery target, and evidence requirements.
- Register the implementation. Bind a fresh instance UUID and exact manifest to an application credential or approved short-lived session.
- Author the smallest root grant. Start from the declared dependencies, remove unnecessary operations, and keep high-risk clients default-deny.
- Verify and sign policy. Run JPC, resolve counterexamples, certify the canonical Cedar-style record, sign it, and activate the expected bundle revision.
- Certify the runtime path. Confirm the application route, provider route, release checksum, health proof, rollback behavior, and network enforcement coverage.
- Enroll node hardware where risk requires it. Verify the device or HSM fingerprint, accept it at the direct parent, and test primary and priority-session failure without proof.
- Add agent authority only after application authority is stable. Begin with shadow proposals, one agent, read-only semantic tools, per-call approval, low call budget, synthetic or non-sensitive data, and a tested kill path.
- Preserve evidence and expiration. Record the exact policy, release, runtime, tool registry, identity generation, proof digests, reviewer, and time-bound authority. Material changes invalidate the affected certification.
The sequence is intentionally incremental. A low-impact employee app can stop after application identity, limited services, visible operations, and a lightweight release path. A regulated or critical workflow adds stronger policy, hardware identity, isolated execution, human approval, and external evidence anchoring without forcing every prototype to carry the maximum burden on day one.
12 · Claims and boundaries
Security architecture is credible only when its limits are explicit.
| Implemented or certified | Not yet claimed |
|---|---|
| Exact application scopes intersected with declared dependencies and root-owned policy | Automatic compliance with a healthcare or financial regulation |
| Deterministic JPC analysis, proof fingerprints, signed Cedar-style bundles, and enforce-mode architecture | A proof about inputs, external systems, or enforcement paths absent from the model |
| macOS Secure Enclave node proof bound to parent, child, API key, role, nonce, expiry, and key fingerprint | Cloud HSM, PKCS#11 appliance, TPM, FIDO2, or compound measured-boot attestation in the current node provider |
| Phase 8 software-held agent assertions, one-use review/touch, replay consumption, and hop-grant digest binding | A live production LLM agent, hardware HSM agent key, passkey, VM isolation, or real host tool execution |
| Rooted branch routing, provider catalogs, exact service operations, typed controls, and bounded audit metadata | Transparent interception of every application connection or an unlimited remote tool platform |
The next architectural milestones are provider interfaces for cloud and appliance HSMs, signed control-matrix receipts, key rotation and revocation-at-use tests, a protected semantic tool broker, VM-bound agent identity, external audit anchoring, and compound runtime attestation. Each should arrive as a separately versioned contract with deterministic certification and fail-closed downgrade behavior.
This publication describes repository architecture and roadmap as of July 2026. It is not legal advice, a compliance attestation, a product certification, or a promise that planned hardware and agent capabilities are production-ready.
Conclusion
Trust should survive the rewrite.
The opportunity is not to freeze AI development until every idea resembles a traditional enterprise system. It is to give experimentation a repeatable route into production—one that becomes stricter as risk grows and remains attributable as code, models, teams, and clouds change.
Janus makes identity the connective tissue of that route. Application grants constrain capability use. Formal verification constrains policy change. Hardware proof constrains node admission. Agent assertions constrain dynamic intent. The resulting mesh is not merely a network of workloads; it is a network of bounded, reviewable decisions.
Architecture basis. This preview paper was developed from the Janus Stack federation, application, service-policy, formal-policy, signed-bundle, hardware-identity, Agent RPC, release, and edge-routing implementations and design records, together with the janus-hsm Phase 0–8 service contract, threat model, certification criteria, and production-agent testing plan. Public claims intentionally distinguish implemented core behavior, a certified static prototype, and planned provider work.