Agentic Security Harness

Your AI coding agent reads untrusted repository text. Can it keep data separate from instructions and authority?

Agentic Security Harness is a local, trace-first benchmark for defensive testing of agentic AI boundary failures. It runs reproducible synthetic scenarios, records portable traces and scorecards, and compares a deliberately vulnerable local agent with a protected one.

In plain English: it turns “the agent behaved unsafely” into evidence you can replay, validate, compare, and review.

Current releases are Harness 1.14.2 and separately owned Action Authority 0.1.1. Harness provides the defensive benchmark and guarded create-only file writer; Action Authority provides exact-action approval with an optional adapter that reuses that writer. Install Harness with python -m pip install agentic-security-harness==1.14.2; an opting-in host can install agentic-action-authority[harness]==0.1.1 separately. Installation does not grant approval or activate an operator workflow. See the integration guide and Harness release record for source pins, verification and limits.

Document workflow — published in 1.13.0

The 1.13.0 release consolidates host-bound document tools, planned and dynamic jobs, retained source restrictions and fenced recovery into one operator workflow. Use the step-by-step guide. The host-bound text tool accepts document content but no model-selected destination or authority. Source restrictions, expected-job coverage and reviewed recovery of existing bytes retain the same guarded create-only writer. Recovery uses a new job; it does not replay or declare the interrupted job complete.

The planned CLI recipe lets a host prepare a finite job plan, execute its jobs and inspect missing work without custom Python glue. It pins input, task, restrictions and declared output checks; exact-byte review happens when the generated document is available. The dynamic admissions path records host decisions under separately retained heads before follow-up jobs.

The document jobs guide covers workspace setup, permission preview, separate jobs, restart inspection, content-free quality status and an optional Pydantic AI bridge around the writer. A verified first document can feed a second job only as untrusted data under unchanged host policy. Exact host-declared criteria are not a claim of factual correctness. The current 1.14.2 package is on PyPI. See its release record for exact subjects and the status of each verification gate; model-task quality and independent human review are separate from package publication.

Current release: 1.14.2. Its attested wheel and sdist are on both indexes with matching hashes. The tag build and TestPyPI workflow passed; PyPI upload and Linux smokes succeeded, but the Windows simple-index lookup failed before package execution, so the initial production workflow remains failed overall. Separate read-only cross-index verification passed all seven jobs without rebuild or re-upload. This patch adds no model study or independent human review.

The historical 1.14.1 release updated the optional Pydantic AI bridge and verification locks to exact pydantic-ai-slim==2.54.0 with matching graph/pricing dependencies.

The historical 1.14.0 release shipped the document-source and bounded workspace controls described below. The merged changes add host-anchored observation admission, exact-byte reviewed source reuse, and fenced recovery for create-only workspace operations. They also update the optional Pydantic AI dependency to 1.107.7. The 1.14.0 tag build, TestPyPI staging and owner-approved PyPI production passed their applicable gates. Separate read-only cross-index verification passed all seven jobs with zero skips; publication does not establish model-task fidelity or independent human review.

The published 1.14.1 optional bridge remains version-bound to 2.54.0. The 1.14.2 package pins 2.55.0 with matching verification locks; it is not a change to the 1.14.1 dependency or new model evidence. Historical PyPI 1.14.0 uses 1.107.7; use files and dependencies from the same revision.

The guarded workspace writer connects an application's agent to real UTF-8 document creation: host-owned configuration, named output aliases, deterministic Guard, no overwrite, and content-free receipts. It includes a reusable Python tool, stdin/file CLI and an explicit one-call local Ollama path. No model is used for the permission decision. The 1.11.0 release record records its verified publication. This tool is not an OS sandbox or a text-accuracy checker. The guide includes a complete first-output example.

Embedded file boundary — published in 1.10.1

Issue #332 tracks the published 1.10.1 release. The new ControlledFileSession lets a trusted application submit bounded proposal bytes through Quarantine, retained ancestry and report-only Guard before a fresh synthetic file effect. An optional Pydantic AI tool example uses fixed offline controls and a separately pinned framework; it is not a base dependency. The eight-case seed is author-authored known data, not independent blind evaluation.

Six earlier local Qwen2.5 1.5B calls through that example produced four report writes, two correct reports and two protected-write denials. Separate offline integration and timing runs are documented with their own limits. Published-wheel Linux/Windows checks used fixed examples, not a new model series. These observations do not establish cross-model reliability; published 1.9.1 artifacts remain immutable. The 1.10.0 tag remains an unpublished failed release gate after its relative-path exporter check failed; it was not uploaded to an index. The 1.10.1 release corrects that path handling without changing runtime authority.

Controlled file effects — published in 1.9.0

Packaging note: the published 1.9.1 patch corrects the package description. Historical 1.9.0 artifacts retain their older description recommending 1.8.0. This patch is not a new protection feature or model result.

Issue #326 tracks the 1.9.0 controlled file workflow with actual writes to fresh synthetic files, report-only Guard enforcement and independent disk checks. Its separate fresh eight-call installed-candidate model observation recorded four forbidden writes denied, four allowed reports written and two correct reports. Release checks are separate; the historical observations below are unchanged.

Previous observation — 2026-09-27

The sixteen-call generalization study records four exact useful tasks, one permitted but semantically wrong hash operation, three rejected useful-task proposals and eight negative controls stopped at their declared boundaries. Five pure operations are not five correct tasks. The local Prometheus model was real; downstream Router transport and adversarial receipt mutations were declared fixtures. Real effects were zero; there was no response repair or retry. This is separate from the garak package-release gates.

Previous verified result — 2026-09-26

The twelve-call local-model follow-up records three real-model proposals completing all seven boundaries of the installed ecosystem, each ending in a built-in constant lookup. All six negative controls stopped at their declared boundary; real external effects were zero. Explicit protocol wording matched both fixed tasks; free wording matched neither capability identifier. This is bounded integration evidence, not a model reliability estimate, an autonomous-agent demonstration or an independent human audit.

• Inspect: fixed public corpus, content-free observations and artifact checks.
• Use the example: explicit proposal protocol. Printing the prompt or checking artifacts does not rerun the model.
• Delivery: merged PR #303. The earlier eight-call result is preserved separately in the report.

Package versus research evidence: the study used exact installed 1.6.0 subjects, while the current published package is 1.14.2. The prompt helper, corpus and observations are repository-owned evidence, not evidence that the 1.7.0, 1.7.1, 1.8.0, 1.9.0, 1.9.1, 1.10.1, 1.11.0, 1.12.0, 1.13.0, 1.13.1, 1.14.0 or 1.14.1 wheel was used in those model calls. See release and package status and current state for the exact boundary.

Experimental garak connection

The published 1.7.0 wheel packages this opt-in adapter. Its attested tag build and exact-wheel TestPyPI staging passed on Linux and Windows; the PyPI upload matches those subjects. Initial Python 3.12/3.13 smokes stopped at a missing same-version PyYAML wheel hash before garak. The corrected read-only verification passed all seven jobs without a new upload. Release evidence and gates keep the prior 1.6.0 evidence separate.

The garak plan connector translates one strictly validated JSON plan into the existing Quarantine/Gateway path, without granting authority from a detector score. A four-case example keeps detection, admission, policy denial and synthetic execution separate. This is an independent Harness integration, not an official NVIDIA/garak component. It is new in the 1.7.0 package, not included in published 1.6.0; its optional detector compatibility lane pins an unmerged upstream PR rather than claiming release support.

Retained ancestry — published in 1.8.0

PR #324 adds an opt-in retained ancestry store: trusted root admission, exact retained parent history, scope narrowing and local crash recovery. Ancestry acceptance cannot override Gateway policy. The exact release subjects are on GitHub, TestPyPI and PyPI; a separate read-only run passed all seven cross-index jobs after the initial production Linux 3.11 index lookup failed before application checks. Release status binds the source, hashes and limits.

Quickstart

Published v1.13.0 extends document jobs around the guarded workspace writer with bound text, reviewed handoff, source restrictions, plans, dynamic admissions and supervised new-job recovery. Historical v1.12.0 introduced the initial document jobs and retains the v1.10.1 embedded file boundary and retains the opt-in controlled file effects from v1.9.0 and the ancestry admission delivered in v1.8.0. The prior v1.7.1 patch repairs known-empty parent authority scope and memory TTL narrowing. The opt-in garak plan adapter, native Ollama proposal adapter, installed-ecosystem pilot, Gateway lookup-key type guard and Router 0.2.1 remain. Release notes distinguish package availability, retained initial smoke failures, and successful read-only verification.

Install the exact package version from PyPI:

python -m pip install agentic-security-harness==1.14.2
ash quickstart --out reports/quickstart
ash agent-host-quickstart --out reports/agent-host-quickstart

For source development:

git clone https://github.com/krivonosoff161/agentic-security-harness.git
cd agentic-security-harness
python -m pip install .
ash quickstart --out reports/quickstart
ash agent-host-quickstart --out reports/agent-host-quickstart

ash quickstart is local and no-network. It runs the same stable 24-pattern corpus against both demo targets, validates the generated artifacts, and renders a self-contained HTML report.

ash agent-host-quickstart is the shipped provider-neutral integration path in v1.1.0. It runs a built-in owned synthetic workflow through the instrumented collector, canonical recordings, deterministic evaluator, atomic bundle publication, and shared validator. It retains digest-only public evidence and makes no provider call.

Runtime Gateway synthetic contour

The source tree now also contains a runnable local Runtime Gateway increment. It applies a closed policy before synthetic tool dispatch, exposes bounded OpenAI-compatible and MCP 2026-07-28 stateless development endpoints, and maintains a privacy-minimized append-only audit chain:

ash gateway-init --out gateway.toml
ash gateway-check --config gateway.toml
ash gateway-serve --config gateway.toml

Open http://127.0.0.1:8787/dashboard after startup, or use the hardened Docker Compose profile in Runtime Gateway synthetic contour. This is a credential-free synthetic integration surface. Offline provider-neutral tool-call adapters normalize retained OpenAI Responses, Anthropic Messages, Google Interactions, and MCP payloads through the same policy without SDKs or credentials. Live provider transport and a production firewall are still not shipped. The gateway exposes its exact closed policy and non-executable approval-request digests; it intentionally has no approval-grant endpoint yet.

Ecosystem map

Harness is the released core and the public contract owner for a modular security ecosystem. Transfer verification, handoff safety, playbooks, routing, filtering, private Runtime Guard research, and the public profile keep their own source-owned component facts. The Harness generates only the cross-project roadmap and compatibility view:

• Ecosystem roadmap
• Components and current integration status
• Documentation crosswalk
• component.yaml and ecosystem/roadmap.yaml

Runtime Guard remains private and contract_only. Harness version v1.14.2 contains the closed Extension SDK V1 and public passive extras for validated observation-to-finding dataflow. It does not auto-load installed packages; companion repositories remain optional, separately versioned distributions.

Version v1.14.2 retains the closed optional-dependency groups introduced in v1.4.0:

Extra	Exact companion distributions	Automatic activation
transfer	agentic-transfer-verifier==0.2.1, extension ==1.0.1	no
handoff	ai-agent-handoff==0.3.0, extension ==1.0.0	no
playbooks	llm-safety-playbooks==0.1.0 data-only wheel	no
router	agentic-llm-router==0.2.1	no
filter	llm-cheap-filter==0.2.0	no
all	the exact union of the five rows	no

The generic PyPI coordinate llm-router is intentionally absent because it belongs to another project. CI builds all eight exact wheels from pinned Git SHAs and installs the closed local wheelhouse without loading either extension entry point. The public install commands are pip install "agentic-security-harness[router]==1.14.2" or pip install "agentic-security-harness[all]==1.14.2". Other companion pins are unchanged; installation remains separate from module activation.

For explicit installed extension binding, follow the fresh --no-compile environment and positive/negative controls in the installed-ecosystem example. The external pilot protocol explains the bounded feedback request.

For the actual six-component flow, run the separate 16-case functional chain and its independent report verifier. Router and Filter APIs execute here; provider transport is an explicit in-memory double. The expert-readiness contract separates this reproducible technical baseline from outstanding human review.

Published Router 0.2.1 includes the lazy HTTP-client import repair; Harness binds its reviewed receipt source to that exact release commit. Installing the package does not call a provider or make the receipt an action grant.

The published Corpus Pack SDK V1 adds a separate, canonical registry for optional namespaced boundary-invariant metadata. It preserves the frozen corpus 1.0.0, loads no package code, and treats complete evidence as readiness for later rule evaluation rather than a security verdict.

The published v1.3.0 companion adapter contracts exercise exact Transfer Verifier reports, Handoff metadata and Playbooks guidance through that SDK on Linux and Windows. This closes a concrete producer-to-consumer dataflow gap; it does not auto-load those installed distributions or make them production enforcement.

The published v1.3.0 Security Intelligence contour adds a provider-neutral offline weekly public-source review contract with digest-only evidence, explicit coverage gaps, and no live fetching or model authority.

The published v1.3.0 receipt auditors independently checks exact-pinned Router invocation and Cheap Filter triage accounting receipts from caller-supplied canonical bytes. Valid accounting remains inconclusive, missing evidence remains inconclusive, and drift becomes a finding; the auditors never emit pass, import or invoke the companion packages, or lower a security decision.

The published Extension Distribution Discovery V1 inspects one explicitly named local distribution without importing it. It verifies its RECORD, closed entry point, canonical manifest, implementation bytes and caller-supplied configuration digest, then requires exact reinspection before issuing an authority-free approval receipt. Harness still does not load package code: the operator supplies an already constructed object, and the binder checks it against the approved manifest pins.

The published Extension Operator Lifecycle V1 exposes that metadata-only inspection and exact-reinspection approval through safe CLI commands, adds canonical disable and non-executable rollback-plan receipts, and lists only explicitly supplied receipt state. It never imports, downloads, starts, stops, or rolls back extension code; the embedding application must construct and bind an object and enforce any accepted disable artifact.

The published controlled local adapter connects only to an operator-started literal-loopback /v1/responses endpoint and passes canonical tool calls through the existing closed Runtime Gateway policy. It supports local model names as opaque identifiers—including Qwen and DeepSeek-style names—without vendor claims. It has no DNS, proxy, redirect, credential, external-provider, arbitrary-tool, or upstream-MCP path; receipts are digest-only and operational authority remains none.

The published Policy Pack extension independently parses one exact-pinned data-only Playbooks pack and evaluates caller-supplied content-free signals bound to canonical observations. A missing pack is inconclusive; production Harness does not import or execute Playbooks code, discover packages, call a network, or grant allow/enforcement authority.

Target	Modeled findings	Patterns passed
demo-agent	24	0
protected-demo-agent	0	24

The deterministic result is 24 modeled findings for the vulnerable fixture and 0 modeled findings for the protected fixture. This is synthetic conformance evidence, not a production safety claim.

Inspect the committed before/after example in examples/comparison-report/ or validate every public example locally:

ash validate examples/
ash validate docs/evidence-status-registry.json

What this is / is not

This project is	This project is not
A reproducible benchmark for agent operating-environment boundaries.	A production safety certification.
A synthetic and authorized defensive testing lab.	A live exploitation or persistence toolkit.
A way to compare vulnerable and protected targets using portable artifacts.	Proof that a provider, model, or deployed agent is secure.
A stable trace/corpus contract with machine-readable validation.	A model leaderboard or CVE database.

The benchmark focuses on agent operating-environment boundaries, not just standalone model answers. Built-in targets are deterministic and offline. The experimental external adapter is explicit opt-in, prompt-only, and does not execute tools. See docs/benchmark-semantics.md and docs/authorized-testing-paths.md.

Visual evidence snapshot

The public evidence map separates deterministic executable specifications, sanitized local observations, historical material, and independently reviewed evidence:

• Evidence map
• Evidence classes
• Machine-readable evidence registry
• Evidence pack format
• Private/public evidence boundary

Public artifacts may include scenario identifiers, aggregate counts, response hashes, and validator results. They do not include raw private prompts, raw responses, synthetic canaries, or local paths. Keep external raw material under .internal/external-demo/latest. Do not commit raw_responses/ or other private runtime evidence.

Current stable surface

• Trace schema 1.0, with a bounded legacy 0.1 read/migration window.
• Corpus 1.0.0, freezing 24 ordered synthetic pattern identifiers.
• Local targets for vulnerable/protected agent, RAG, tool, function, and multi-agent handoff comparisons, including toy-multi-agent and protected-toy-multi-agent.
• JSON traces, scorecards, run manifests, remediation, Markdown reports, and self-contained HTML reports.
• Deterministic validators for artifact integrity and declared benchmark semantics.
• Linux/Python 3.11-3.13 as the primary installed-package contour, with Windows 3.11 compatibility coverage.
• Reproducible wheel/sdist builds, checksums, GitHub attestations, and exact-subject CycloneDX SBOMs for public releases from v1.0.0 onward.
• A shipped provider-neutral Agent Host V1 contour for canonical, authority-free record/replay, deterministic evaluation, explicit Python instrumentation, and a validated 48-case no-network quickstart. The CLI does not execute arbitrary hosts or tools and does not authenticate its producer or certify an external system; see Agent Host Adapter SDK.
• A shipped local Runtime Gateway synthetic contour with closed pre-dispatch policy, bounded OpenAI-compatible and stateless MCP endpoints, deterministic synthetic tools, privacy-minimized hash-chain audit, dashboard, and hardened source-build Docker Compose.
• Credential-free retained-envelope normalization for OpenAI Responses, Anthropic Messages, Google Interactions, and MCP tool calls. These adapters do not make provider calls or grant tool-execution authority.

The exact shipped, experimental, planned, and historical surfaces live in docs/current-state.md and docs/capability-matrix.md. Technical v1 gates and honest non-claims are in docs/v1-readiness.md.

If you only have one minute

• Run the no-network demo above.
• Read the committed comparison.
• Browse the showcase and scenario matrix.
• See weak spots and findings.
• Check current state and the project tracker.
• Bring your own local or OpenAI-compatible model through Run your model.

Use your own model or runtime

The shortest cross-platform operator path is docs/run-your-model.md. It covers:

1. a no-model deterministic demo;
2. one explicitly authorized OpenAI-compatible model;
3. a deterministic local swarm comparison;
4. a bounded local-model mini-swarm campaign.

Connection details and scenario selection are documented in docs/connect-models.md and docs/test-your-model.md. External runs are prompt-only self-report checks unless a separately reviewed host/tool adapter exists. A coherent answer is not evidence of safe tool execution.

Benchmark and evidence documentation

Start with the curated documentation map if you are not sure which contract, operator guide, or research page applies to your task.

The README is the front door; deeper contracts live in docs/:

Question	Source of truth
What is shipped now?	Current state
What work is open?	Project tracker and roadmap
Which testing paths are authorized?	Authorized testing paths
Which system shapes are evaluated?	Evaluation topologies
What boundary model is used?	Agentic boundary model
How is the corpus expanded?	Corpus expansion plan
What do metrics mean?	Metric contract
How are scenarios sequenced?	Scenario timeline
How should reports be showcased?	Showcase checklist
How is evidence promoted?	Evidence pack format
How are changes reviewed?	Git evidence workflow
How can an external agent host record and evaluate observations?	Agent Host Adapter SDK
How can I run the local policy gateway and MCP/OpenAI-compatible demo?	Runtime Gateway synthetic contour
How are provider tool-call envelopes normalized without credentials?	Provider-neutral tool-call adapters
How can native Ollama output reach Quarantine and a pure Gateway decision without dispatch?	Native Ollama adapter (published in 1.6.0)
How do optional components exchange validated observations and findings?	Extension SDK V1
How is an installed extension distribution verified before explicit registration?	Extension Distribution Discovery V1
How does an operator approve, list, disable, or plan rollback without automatic code loading?	Extension Operator Lifecycle V1
Which companion contracts already have executable cross-repository adapters?	Companion Extension adapters
How are weekly public security inputs reviewed without provider lock-in?	Security Intelligence extension
How can optional packages add patterns without overriding the stable corpus?	Corpus Pack SDK V1
How can an operator connect one local model without opening arbitrary tools?	Controlled local provider/tool-host adapter
How is the reviewed Playbooks Policy Pack evaluated without importing its code?	Policy Pack V1 extension

Specialized reviewer paths:

• Local Prometheus workflow
• Local model profiles
• Multi-agent handoff toy topology
• Security audit causal map
• R5 sanitized research status
• Project governance

Standards and portfolio boundaries

The project publishes conservative mappings to OWASP LLM, NIST, and a direct-fit MITRE ATLAS subset in docs/standards-mapping.md. These are maintainer-reviewed mappings, not certification or independent standards validation. Independent review remains public follow-up work.

The related public contract includes:

• Threat ontology: 26 provider-neutral failure families.
• Scenario adjudication ledger: 127 bounded source units from 13 enumerated builders.
• Unified event envelope: separation of observations, data, authority, advisories, decisions, and effects.

The 127 units are not 127 canonical attacks and not a repository-wide total. The contract grants no executor, provider, deployment, enforcement, or production authority.

Public security stack

Agentic Security Harness is the benchmark/evidence layer in a small public defensive stack:

llm-safety-playbooks -> ai-agent-handoff -> agentic-transfer-verifier -> agentic-security-harness

• llm-safety-playbooks documents practical boundary rules.
• ai-agent-handoff represents task briefs and handoff state as reviewable files.
• agentic-transfer-verifier checks provenance, authority, approval, and audit evidence around transfers.
• This repository measures modeled failures and produces validated benchmark artifacts.

The repositories are related but not interchangeable. A playbook is not a runtime control, a handoff file is not a sandbox, and a passing benchmark is not a production certificate. The review-only ecosystem integration candidate builds the optional Transfer and Handoff extension wheels and exercises their explicit approval lifecycle on Ubuntu and Windows; it does not bundle or auto-install them.

Release and package status

Release v1.14.2 is published on PyPI. Its tag build 39062758733 passed four jobs and TestPyPI 39063210754 passed three. PyPI 39063481449 uploaded the matching subjects and passed Linux 3.11–3.13, but Windows failed at simple-index lookup before execution; that workflow remains failed overall. Separate read-only 39063673573 passed all seven exact-subject cross-index jobs without rebuild or re-upload. Historical release v1.14.1 is published on PyPI. Its exact tag build 38341102704 passed four jobs. Initial TestPyPI 38341625568 uploaded but failed overall at Linux index lookup before package execution; read-only staging recovery 38342022902 passed all three jobs without re-upload. Production 38345333268 uploaded the same verified subjects and passed Linux 3.11/3.13 and Windows 3.11 smokes, but failed overall because Linux 3.12 could not find the version in the simple index before package execution. Separate read-only cross-index run 38345501324 passed all seven jobs with zero skips against the unchanged subjects, without rebuild or re-upload. Historical release v1.14.0 is published on PyPI. Its tagged build 38304932507, TestPyPI staging 38305530516, and owner-approved production 38307086412 passed four, three and five applicable jobs, respectively. Official non-yanked wheel/sdist hashes match attested subjects; separate read-only cross-index run 38307456388 passed all seven jobs with zero skips. Historical v1.13.1 retains its own tag build 37904553744, TestPyPI 37926491472, PyPI 37964360307 and seven-job read-only run 37966053148. Historical v1.13.0 passed its own five applicable production jobs and separate read-only run 37764340666 passed all seven cross-index jobs with zero skips. Historical v1.12.0 retains its own exact subjects, platform checks and seven-job read-only verification. The prior v1.10.0 tag remains failed and unpublished. Historical v1.11.0 retains its initial production Linux 3.11 index-lookup failure and later seven-job read-only pass. Historical v1.10.1 passed its own publication and read-only checks; its subjects were not replaced. Historical v1.9.1 corrected the package description; its initial TestPyPI Windows and PyPI Linux 3.12 lookup failures remain failed workflow results. Historical v1.9.0 delivered the opt-in controlled-file workflow, limited to fresh synthetic fixtures. Its installed-candidate model observation is separate from either release verification.

Historical v1.8.0 is published on PyPI. Its wheel and sdist match the attested tag build and TestPyPI. The owner-approved production upload succeeded; Linux 3.12/3.13 and Windows 3.11 passed, but the initial Linux 3.11 simple-index lookup failed before application checks. The separate read-only verification passed all seven cross-index jobs without another upload. This delivers bounded retained ancestry admission; independent coverage, recovery and the other foundation questions remain open.

Release v1.7.1 is available on PyPI. Its wheel and sdist match the attested tag build and TestPyPI. Initial TestPyPI Windows and PyPI Linux 3.11–3.13 simple-index lookups failed after successful uploads; the read-only verification passed all seven subject and cross-platform install jobs without another upload. This patch does not turn the five open foundation research questions into shipped features or general security proofs.

Release v1.7.0 is available on PyPI with wheel and sdist hashes matching the attested tag build and TestPyPI. Its new garak plan adapter is explicit and optional. The initial production/read-only workflows retain Python 3.12/3.13 dependency-lock failures. A separately corrected read-only run passed all seven jobs without a second upload. The installed-ecosystem example provides version-specific hash-locked routes with positive and negative controls.

The repository also contains the 16-case functional chain, caller-input checks and bounded local-model evidence above. Those observations retain their exact 1.6.0 installed-subject commitments; publishing 1.7.0 does not rerun or rewrite them. The example scripts and reports remain repository-owned, with the current hash-locked install routes documented in their README. Published 1.6.0 subjects and their embedded documentation remain immutable.

The following prior release evidence is retained without rewriting its outcomes.

Prior release v1.5.1 is published on PyPI and GitHub Releases. Published-release verification passed exact-subject provenance/index checks and clean Linux/Python 3.11-3.13 plus Windows/Python 3.11 installation. Publication makes the bounded core and selected passive distributions installable; it is not automatic activation, production deployment, enforcement, provider authority, or security certification.

The v1.5.0 release adds explicit Quarantine and advisory-to-Gateway composition plus exact-pinned external Playbooks receipt ingress. These pure APIs stop at a Gateway decision: they do not dispatch, activate companions, authenticate producers or infer safe model intent. The v1.5.1 notes retain the initial TestPyPI and Windows PyPI index-lookup failures and successful read-only recovery; no published package was rebuilt or uploaded again. Historical v1.5.0 verification 35507083204 and its release artifacts remain unchanged.

• Release checklist
• PyPI release process
• Changelog
• Security policy

Independent standards review and a durable second GitHub reviewer are transparent post-v1 credibility tasks. Their absence does not change deterministic test results, but independent review is not claimed.

Development

python -m pip install -e ".[dev]"
python -m pytest
python -m ruff check .
python -m mypy src tests tools
ash validate examples/

Development follows idea -> issue -> branch -> implementation -> tests/artifacts -> PR -> GitHub checks -> review gate. See docs/git-evidence-workflow.md, CONTRIBUTING.md, and docs/agent-operating-guide.md.

Responsible use

Use only synthetic, local, owned, or explicitly authorized targets. Do not use this project for credential theft, persistence, evasion, destructive payloads, or unauthorized systems. See SECURITY.md and docs/authorized-testing-paths.md.

Citation, contributing, and license

• Citation metadata: CITATION.cff
• Governance: GOVERNANCE.md
• Contributing: CONTRIBUTING.md
• Support: SUPPORT.md
• License: Apache-2.0, see LICENSE and NOTICE