Seven layers, one stack, every action mediated.

The Policy Engine is the first layer every prompt encounters. It resolves which policy applies to this prompt, in this context, for this user — based on the user's identity (from the SSO layer), the agent that's processing the prompt (from the agent registry), the tools the agent might invoke (from the tool registry), and the data classifications in scope (from the file pillar's classification metadata).

Policy resolution happens before the prompt reaches the model. The output of the Policy Engine is a structured policy document (JSON Schema validated) that downstream layers consume — Layer 2 reads it to decide which firewall rules to apply, Layer 3 reads it to decide which tools the agent is permitted to invoke, Layer 5 reads it to decide which inter-agent boundaries are enforceable.

Policies are written in a YAML DSL. A policy can reference: identity attributes (department, clearance, role), data classifications (PII, PHI, financial, regulated), tool categories (read, write, external, communication), agent roles (Pilot, Hunter, Sentry, Concierge, Analyst, Custom), and time windows (business hours, after-hours, locked-down).

Prompt Defence is the inline firewall. Every prompt that has passed Layer 1 (Policy resolved) reaches Layer 2 next. The firewall — internal codename NemoClaw — applies the active rule set against the prompt before it reaches the model.

The rule set is the NemoClaw ATLAS rule library — currently 28 active rules covering: direct prompt injection (instruction override attempts, role-play escapes, payload smuggling), indirect prompt injection (poisoned RAG content, malicious tool output, file-borne injection vectors), data exfiltration patterns (training-data extraction probes, embedding inversion, system-prompt elicitation), and the canary-token detection patterns (used to detect injection attempts that try to mask themselves as legitimate completions).

Canary tokens are the structural defence against the “invisible” injection class. The platform inserts deterministic canary tokens into the prompt at well-known positions; the model's response is then scanned for whether the canary was preserved, modified, or substituted. A modified canary indicates the model's response was steered by injected content rather than by the user's intent.

NemoClaw runs in two modes: block (the prompt is refused, an audit event is logged, the user sees a structured error) and flag (the prompt proceeds, but is annotated for downstream layers, particularly Layer 4's memory safety check). The choice between block and flag per rule is policy-driven (Layer 1).

When the model produces a response that includes a tool call (e.g. “send an email to alice@example.com with subject X”), the tool call does not execute immediately. It enters Tool Guardrails first.

Tool Guardrails performs three checks before execution:

1. Permission scope check. Does the agent that produced the tool call have permission to invoke this tool with these parameters? The permission scope is enforced from the policy resolved at Layer 1; the tool registry knows which agent roles can invoke which tools and under what restrictions.
2. Parameter validation. Are the tool's parameters well-formed? Does the email address pass syntactic validation? Does the file path resolve within the agent's permitted scope? Does the API endpoint match the registered tool's allowed endpoint pattern?
3. Side-effect classification. Is this tool call read-only, modifying, or external? Read-only calls execute. Modifying calls require user confirmation if the agent's permission scope demands it. External calls (anything that leaves the platform's trust boundary) require explicit user consent and are flagged in the audit log with the destination domain.

If any of the three checks fails, the tool call is rejected, an audit event is logged, and the model is given the rejection back as part of its conversation context (so the model can either retry with corrected parameters or report the failure to the user). The model never bypasses the guardrails.

Memory Safety governs what the agent remembers, across what conversational scope, for how long. It addresses the failure mode where information from one session leaks into another — typically because a long-running conversation context inadvertently carries forward content that should have been scope-isolated.

The layer enforces conversation isolation: each user-agent session has its own memory scope, with a strict TTL (configurable by policy, default 24 hours), and content from one session is not surfaced as context for another session unless explicitly authorised. Agents cannot read each other's memory. The Pilot orchestrator does not retain content from specialist agents' working memory beyond the orchestration window.

The layer also enforces cross-tenant isolation — but this is an availability defence, not a privacy defence, because Vantage Workspace is single-tenant by deployment model (each customer gets their own deployment). The cross-tenant layer is a defence-in-depth: even within a single deployment, agents serving different organisational units cannot access each other's working memory.

The layer also runs embedding inversion detection — periodically sampling the embedding store for patterns that match known model-extraction probe shapes, flagging the responsible agent for review.

Trust Boundaries enforces the rules around inter-agent communication. When the Pilot delegates a task to a specialist (Hunter, Sentry, Concierge, Analyst), the delegation message itself crosses a trust boundary. Trust Boundaries validates the message:

• The Pilot is authorised to delegate to this specialist.
• The specialist is authorised to receive this delegation.
• The delegation payload is well-formed (matches the expected schema for this specialist).
• The delegation does not exceed rate limits (preventing the “agent storm” denial-of-service pattern).

The layer also enforces role isolation: the agent that proposed an action is not the same agent that validates it. The Pilot proposes; a specialist executes; a separate review path (in the policy-permitted cases) validates. The “excessive agency” failure mode — where one agent decides, executes, and audits its own decision — is structurally prevented.

For human-in-the-loop scenarios, the Trust Boundaries layer enforces the consent surface. A modifying tool call (Layer 3, side-effect: modifying) that policy says requires user consent triggers a Trust Boundaries check — the consent message is delivered through a separate, identity-rooted channel (typically the user's chat client), and the consent response is verified before the tool call executes.

The twenty platform containers communicate over the network. Layer 6 is the rule that says: every service-to-service communication is authenticated using mutual TLS (mTLS), with certificates rooted in a per-deployment certificate authority operated by the identity service.

There are no shared service-account API keys. There are no INTERNAL_API_TOKEN environment variables. A service that has not presented a valid mTLS certificate cannot make a request to another service. A service whose certificate has been revoked (because the operator rotated it, because the certificate's expiry has passed, or because the identity service detected anomalous behaviour from that service) cannot continue to make requests.

Certificate rotation is automatic — every certificate has a 24-hour TTL by default, with renewal handled by the identity service. The operational impact: a compromised service container's blast radius is bounded by the rotation interval, because the compromised certificate stops working within 24 hours.

The layer also produces evidence for Layer 7 (Supply Chain) — every certificate issuance includes a cryptographic attestation of the requesting service's container image hash, which Layer 7 verifies against the supply-chain manifest.

Supply Chain is the layer that verifies the platform itself — the container images, the dependency manifests, the model artefacts, the policy bundles — at load time and continuously thereafter.

Every container image shipped by Handvantage has a cryptographic manifest signed with our publishing key (root of trust published at /.well-known/handvantage-publishing-key, also rotated quarterly with overlap). The manifest declares: the image's content hash, the SBOM (software bill of materials) for every dependency, the model artefact hashes for any pinned model versions, and the build-provenance attestation (SLSA Level 3 minimum).

At deployment time, the operator's install pipeline verifies every image's manifest against the published key. At runtime, the platform's supply-chain service periodically re-verifies — mostly to detect accidental drift (e.g. an image that was retagged in the customer's local registry without re-attestation) and to detect any publishing-key revocation.

For customer-supplied components (custom agents, custom tools, custom policy bundles), the same manifest discipline applies at install time. A custom agent without a signed manifest cannot be loaded into the agent registry. The customer signs their own manifests with their own key; the verification is local.