17  Security, Evaluation, and Production Gates

Part IV · Portability in production

Evidence baseline: deterministic reference tests + scoped live records · production classification: not approved

A passing model demonstration is not a security test, and a passing deterministic test is not production certification. The reference is a loopback educational system. Production approval requires authenticated ownership, stronger isolation, reviewed egress and recipients, operational budgets, adversarial evidence, and a reversible release decision.

A production gate is an independently reviewable condition that must pass before a named deployment and task profile can receive real users or data. A gate names evidence, scope, owner, expiry, and failure action; it is not a confidence score supplied by the system being evaluated.

17.1 Start with assets and trust boundaries

The system handles several asset classes:

• provider credentials and endpoint configuration;
• user prompts, attachments, images, and source URLs;
• extracted document representations and invocation-local IDs;
• tool schemas, policy decisions, approvals, and results;
• generated answers, citations, presentations, and artifact IDs;
• transcript, recovery, and operation-state records;
• progress events, diagnostics, traces, and test evidence; and
• dependency locks, manifests, configuration, and release metadata.

Its principal trust boundaries are:

user / Pi client
  → HTTP input admission
  → coordinator provider
  → server-owned policy and tools
      → public network
      → secondary model recipient
      → document/parser workers
      → local Python/presentation workers
  → artifact handoff and local save
  → retained state / telemetry / publication

Every arrow is a data-recipient or authority decision. “The model is trusted” is not a useful threat statement: model output remains untrusted even when the provider and account are approved. Retrieved, attached, generated, image-derived, document, skill, gallery, presentation, and delegated-agent content remains data, never control-plane authority.

17.2 Threat model

The reference should be evaluated against at least these actor classes:

• an unauthenticated local process reaching the loopback listener;
• a legitimate user supplying malformed, oversized, hostile, or confidential content;
• a compromised or malicious public source;
• model output attempting to widen tools, recipients, limits, or paths;
• a remote provider returning malformed streams, unsafe text, or ambiguous terminal state;
• a dependency/parser/runtime defect;
• a compromised secondary service or telemetry recipient;
• concurrent users attempting cross-tenant access;
• an operator making a configuration or release mistake; and
• a reviewer overgeneralizing narrow evidence.

The current service assumes a trusted single-user workstation and binds to loopback. Loopback reduces exposure; it is not authentication. Another process under the same account can connect, and local extensions execute with user permissions.

17.3 Authentication and tenant ownership

The live handler currently mints principal: local-development and tenant: loopback. HTTP bodies cannot override them, which prevents a caller from self-assigning a server identity. It does not authenticate a human or isolate multiple tenants.

A production gate requires:

1. an authenticated principal derived outside request content;
2. tenant/organization ownership bound to that principal;
3. session and artifact lookup scoped to both values;
4. service-to-service authentication for every remote executor;
5. revocation and credential-rotation behavior;
6. non-disclosing authorization failures; and
7. tests for cross-tenant reads, writes, caches, artifacts, traces, and recovery.

A session ID, source ID, artifact ID, provider response ID, or trace ID is a lookup/correlation value, not proof of access. The SQLite transcript example compares trusted owner values but explicitly does not authenticate them.

17.4 Authorization and approval

Authentication answers who is calling. Authorization answers whether this principal may perform this operation on this data with this recipient now. Approval captures a task- or user-specific decision when policy requires one.

The policy runtime validates schema, checks current authorization and approval, rechecks cancellation, executes the compiled tool, validates output, and records a bounded outcome. Important production additions include:

• entitlement lookup under bounded latency;
• grant expiry and revocation;
• binding approval to normalized operation intent;
• destination and data-class restrictions;
• separation of read, compute, publish, overwrite, and delegate permissions;
• durable consequential-effect receipts; and
• protected audit evidence.

A model proposal, skill instruction, retrieved sentence, old transcript, generated summary, or successful previous run cannot become authorization. Persisted history grants no execution authority.

17.5 Network egress and SSRF

read_source implements public-HTTPS syntax checks, DNS/address screening, mixed-address rejection, pinned transport, hostname TLS validation, default-port policy, no ambient proxy, no credentials, no redirects, bounded response handling, and shared ingestion. These controls substantially narrow server-side request forgery.

They do not replace:

• an OS/network egress firewall;
• maintained public/special-use address classification for every supported family;
• controlled DNS infrastructure and rebinding tests;
• destination allowlists for sensitive deployments;
• per-tenant network policy;
• proxy and service-mesh review;
• monitoring of denied and anomalous destinations; or
• secure redirect support if redirects are later enabled.

Hosted search and model providers are separate approved egress recipients. Their SDK endpoint overrides and credentials belong to trusted environment/bootstrap configuration, never model/tool arguments or agent.yaml fields.

17.6 Document and parser isolation

The ingestion boundary validates declared bytes, media/profile, image dimensions, archive expansion, entries, nesting, pages, cells, entities, parser iterations, extraction deadlines, and canonical-text limits. Xberg work runs in a killable worker, and unsupported/encrypted/incomplete documents fail with bounded categories.

A parser worker in the same application account is not strong isolation. Production document handling requires:

• a separate process/container or service identity;
• read-only ephemeral input mounts;
• no ambient credentials or network;
• CPU, memory, file, process, and wall-clock limits;
• decompression and temporary-storage quotas;
• hardened image/document libraries and patch policy;
• malformed-corpus and known-vulnerability testing;
• cleanup verification after kill/crash; and
• output schema and byte validation at the trust boundary.

Model-backed layout inference remains disabled because local model artifacts have not been separately admitted. Enabling it would add dependency, compute, recipient, provenance, and evaluation gates.

17.7 Production code-execution isolation

The Pyodide interpreter creates a fresh worker, uses fixed invocation-local mounts, blocks ordinary JavaScript-bridge/package-installer imports, declares no network/packages/arbitrary host paths, and terminates on timeout/cancellation. This is useful defense in depth for a local reference.

It is explicitly not a safe hostile multi-tenant sandbox. Production execution requires:

• process/container/VM isolation under a dedicated identity;
• OS-enforced CPU, memory, process, file, and output quotas;
• default-deny network at the kernel or infrastructure layer;
• immutable reviewed runtime images;
• no host credential or socket inheritance;
• seccomp/sandbox profile where applicable;
• bounded queue fairness and tenant quotas;
• image provenance, vulnerability scanning, and patch SLAs;
• escape and denial-of-service testing; and
• independent kill/cleanup evidence.

The same principle applies to presentation generation. OOXML package inspection rejects active content and external relationships, but the worker and office-rendering acceptance environment still need isolated identities and controlled file access in production.

17.8 Prompt injection and untrusted content

Prompt injection is not solved by telling the model that content is untrusted. OWASP guidance distinguishes direct and indirect injection and recommends layered controls rather than prompt-only separation (OWASP, n.d.).

The reference’s enforceable controls include:

• static tools and skills;
• strict typed arguments;
• server-owned recipients, credentials, limits, and paths;
• invocation-local source IDs;
• policy/approval outside the model;
• no execution of skill scripts;
• retrieved text that cannot register capabilities; and
• bounded output/rendering validation.

Residual risk remains:

• the model can choose an allowed tool for the wrong reason;
• a malicious source can influence synthesis or select sensitive search terms;
• permitted tools can be composed into harmful data flow;
• final prose can follow hostile instructions despite server enforcement;
• Pi-local tools have their own policy boundary; and
• semantic misuse can occur without violating a schema.

Evaluation must count forbidden effects and data releases, not merely whether the answer says “I ignored the instruction.”

17.9 Provider and recipient disclosure

A portable route can have several recipients. In the Northstar run:

• Anthropic coordinates;
• OpenAI receives one admitted image plus focused question;
• OpenAI hosted search receives focused public terms;
• the selected public origin receives an HTTPS read;
• Pyodide and PptxGenJS run locally.

Production admission must maintain a data-flow matrix for each operation:

Operation	Recipient	Minimum released data	Disclosure/evidence
Coordination	Selected model route	Prompt and admitted context	Provider/model class, policy
Image understanding	Fixed secondary model	One image + question	Explicit recipient + generated status
Search	Fixed search model/public search	Focused query	Recipient/network/cost disclosure
Source read	Selected public origin	HTTPS request metadata	Admitted URL/representation record
Local computation	Isolated runtime	Selected snapshots + code	Runtime/revision/limits
Presentation	Isolated local worker	Semantic deck + admitted images	Artifact digest/byte count
Telemetry export	Collector/backend	Closed safe attributes	Recipient/retention/sampling policy

Choosing a coordinator does not automatically consent to every secondary recipient. Region, retention, contractual terms, and data classification must be evaluated independently.

17.10 Secrets and diagnostics

Credentials remain in trusted environment/bootstrap settings and are never valid YAML fields, tool arguments, model context, progress events, or evidence artifacts. Pi credentials are not read by the server. Endpoint overrides require explicit operator approval.

Public errors use controlled categories. Safe diagnostics omit queries, document text, images, generated observations, Python code/output, credentials, headers, raw provider messages, and bodies. OpenTelemetry uses a closed attribute allowlist and excludes opaque IDs by default.

A production gate includes:

• secret-manager integration and rotation;
• least-privilege provider credentials;
• environment/process-dump review;
• log/trace redaction tests, including encoded and chunk-split forms;
• access-controlled diagnostic retention;
• incident-reference non-disclosure across tenants; and
• a scan of source, build artifact, container, configuration, and history.

Hashing sensitive content is not anonymization. Predictable prompts, URLs, or IDs can be guessed.

17.11 Rate, cost, deadline, and concurrency controls

The reference has per-invocation calls, sources, bytes, steps, deadlines, queueing, and output bounds. These are necessary but not production quotas.

A production service requires coordinated budgets across:

• principal and tenant;
• route/provider/account;
• task/session and HTTP invocation;
• search, retrieval, image, computation, and presentation;
• concurrent active workers and queued work;
• model tokens and provider currency estimates/measurements;
• artifact and retained-state storage; and
• retry/fallback amplification.

One owner must coordinate retry attempts. A six-hour request ceiling does not guarantee affordable completion. Provider-requested token/tool limits are not independently enforced remote CPU/billing limits. Unknown usage remains unknown and must not be converted to zero.

Rate limiting itself needs abuse tests and safe failure behavior. Queue bounds must prevent one tenant from starving others. End-to-end deadlines cannot reset on every model round, progress event, or retry.

17.12 Artifact and retained-state security

Presentation artifacts use random short-lived IDs, no listing endpoint, exact length/digest verification, mode 0600, and replacement confirmation. Production requirements add:

• authenticated tenant-bound retrieval;
• encrypted storage where required;
• bounded leases and deletion;
• malware/content scanning appropriate to format;
• immutable audit metadata;
• download headers and content-type enforcement;
• replacement/version policy; and
• backup/retention treatment.

Transcripts, retrieval memory, provider continuation, summaries, and operation ledgers have different authority and deletion rules. A generated summary cannot preserve approval. A transcript is not a remote effect receipt. Opaque provider state remains sensitive even when unreadable.

17.13 Evaluation stack

No single evaluation establishes production fitness. Use layers with distinct claims.

17.13.1 Deterministic invariant tests

Credential-free tests under network denial cover schema, policy, quotas, cancellation, event order, parsing, citations, cache ownership, artifact structure, digest handoff, telemetry redaction, and known failure cases. They establish local code behavior under fixtures.

They do not establish live provider compatibility, model quality, parser security against unknown exploits, or production operations.

17.13.2 Protocol and conformance suites

A pinned external suite measures a named protocol revision and target. Preserve all failures and the suite’s exit status. Chapter 19 reports 8 passed, 9 failed, 0 skipped and classifies the server as a compatible subset, not conformant.

A suite pass is not a security assessment. Implementing prompt-specific behavior to satisfy cases is unacceptable.

17.13.3 Live transport evidence

Live records name date, exact commit, account/endpoint class, provider/model, request profile, observed outcome, cost context, and limitations. They establish that exact route under those conditions. They expire as evidence when configuration or dependencies change.

17.13.4 Semantic/task evaluation

Task evaluation starts from the promise. Northstar gates include evidence-class preservation, required tool procedure, correct two-premise comparison, missing/conflicting evidence behavior, recipient disclosure, and artifact integrity.

Use paired providers only when both are admitted for the same task profile. Shared interfaces do not establish semantic equivalence. Measure disaggregated errors and forbidden effects; do not average an authority violation into a quality score.

17.13.5 Adversarial evaluation

Include malicious documents, prompt injection, ambiguous identifiers, conflicting measurements, oversized/decompression inputs, stale/cross-tenant IDs, hostile URLs/DNS, malformed streams, duplicate terminal events, cancelled approvals, queue starvation, artifact replacement, and raw-error/secret echoes.

Success criteria should name effects: no unauthorized dispatch, no forbidden recipient, no cross-tenant read, no unreviewed overwrite, no unsafe package, and no content leak in progress/diagnostics/telemetry.

17.13.6 Manual artifact review

Manual review applies to exact bytes under exact renderer/application versions. It can assess layout and comprehensibility that OOXML checks cannot. It cannot certify future generated decks or every office suite.

17.14 Fault-injection program

Production readiness requires failures at boundaries, not only invalid input:

• disconnect before/after provider acceptance;
• malformed or duplicated stream terminal events;
• provider timeout after partial output;
• cancellation while policy/approval waits;
• process kill during worker execution;
• remote effect commit before local receipt;
• transcript write failure on multi-record append;
• stale revision under concurrent writers;
• DNS answer change and redirect attempt;
• full telemetry/export queue;
• artifact store restart/expiry during handoff; and
• dependency or parser crash.

Each scenario records visible output, effect knowledge, durable state, allowed next action, and whether reconciliation exists. Cancellation never becomes permission to repeat an uncertain effect.

17.15 Release approval gate

A release candidate is approved only for a named deployment/task profile after reviewers sign these categories:

1. Identity and authority—authentication, tenant ownership, entitlements, approvals.
2. Recipients and data flow—providers, network origins, collectors, regions, retention.
3. Isolation and resources—parsers, code, presentation, network, queues, quotas.
4. Correctness—deterministic tests, protocol suite, task evaluation, failure behavior.
5. Privacy and diagnostics—secrets, logs, progress, traces, artifacts, state.
6. Operations—monitoring, reconciliation, incident handling, capacity, backups/deletion.
7. Supply chain—exact dependencies, licenses, provenance, vulnerability review, workflow pins.
8. Rollback—previous safe version/configuration, state compatibility, traffic and credential plan.

The release record binds commit, Bun/Quarto/runtime versions, lock digest, configuration, tests, suite revision/results, live evidence, known defects, artifact hashes, reviewers, date, expiry, and limitations. Approval is scoped; it is not a permanent product certificate.

17.16 Rollback is a state transition

Rollback must answer:

• Can the old version read new transcript/evidence schemas?
• Are provider or tool grants still valid?
• What happens to in-flight requests and unknown effects?
• Are new artifacts/state retained or quarantined?
• Must credentials be rotated?
• Does the rollback restore a known vulnerability?
• Which live/conformance evidence no longer applies?

A binary rollback that ignores durable state can corrupt recovery. Prefer forward-compatible readers, explicit schema gates, drain/reconcile procedures, and reversible configuration flags. Never replay pending transcript calls merely because deployment changed.

17.17 Current blocked production claims

The reference does not currently establish:

• authenticated multi-user or tenant isolation;
• production entitlement/approval infrastructure;
• OS-isolated hostile document or Python execution;
• comprehensive prompt-injection resistance;
• destination-complete egress enforcement;
• durable source/artifact/effect identity across requests;
• formal local-file citations for every parser profile;
• exactly-once consequential effects;
• production OTLP export, metrics, or log correlation;
• MCP or A2A interoperability;
• semantic equivalence across providers;
• compatibility with every office suite; or
• formal Open Responses conformance.

These are blocked claims, not hidden roadmap details. The loopback reference can still provide valid educational evidence for its narrower implemented boundaries.

17.18 Pattern summary

Problem: A working demo and large test count can obscure missing identity, isolation, recipient, recovery, and operational controls.

Pattern: Define assets and trust boundaries, keep authority outside content, layer deterministic/protocol/live/semantic/adversarial evidence, and require a scoped release and rollback record.

Result: Production becomes an explicit decision about a named deployment and task rather than a marketing inference from generated output.

Cost: Authentication, isolation, egress, evaluation corpora, fault injection, operational ownership, and recurring evidence review remain substantial engineering work.

17.19 Exercises

1. Build a recipient matrix for a confidential Northstar variant. Identify which current routes must be disabled.
2. Specify a multi-tenant artifact lookup and test that random IDs alone do not grant access.
3. Design a process-isolated code runner with OS resource and egress controls. State what Pyodide checks remain useful.
4. Create an indirect-injection test whose success criterion is zero forbidden effects rather than refusal wording.
5. Draft a rollback plan across a transcript schema change and an unresolved publication effect.

17.20 Chapter contract

• Scope: threat boundaries, authentication/authorization, isolation, injection, egress, recipients, secrets, budgets, evaluation, fault injection, release, and rollback.
• Canonical claims: the current loopback reference is not production-security certified; production approval requires scoped evidence across every trust and effect boundary.
• Migration inputs: security sections across tool/document chapters, publication/artifact checks, live-evidence policy, and implemented telemetry redaction.
• Evidence gates: deterministic invariants, protocol results, dated live records, task/adversarial evaluation, fault injection, and signed release/rollback records.
• Demonstration slots: Northstar and document inspection are scoped functional evidence only, never production certification.
• Source-claim ledger: security guidance and mutable provider/protocol claims retain source revision, review date, implementation scope, and limitation.
• Exclusions: concrete tool mechanisms stay in their owning chapters; final Open Responses classification belongs to Chapter 19.

OWASP. n.d. “LLM Prompt Injection Prevention Cheat Sheet.” Accessed October 8, 2026. https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html.