Skip to main content

Agentic Security Harness

Distribution version: 1.13.1. Python 3.11 or newer. Apache-2.0.

A local defensive benchmark and toolkit for testing agent boundary failures: untrusted input, authority confusion, retained history and controlled file actions. It produces replayable traces, scorecards and separately verifiable evidence.

This description belongs to the distribution you are viewing. For live publication status, exact artifact hashes and verification runs, see the release records and current project state. Version metadata alone does not attest index availability or publication.

Install this version

python -m pip install agentic-security-harness==1.13.1
ash quickstart --out reports/quickstart

Use a fresh output directory. The quickstart runs fixed offline scenarios against vulnerable and protected fixtures; it does not call a model or an external target.

Check a controlled file boundary

ash controlled-file-workflow --out reports/file-boundary
ash controlled-file-verify --out reports/file-boundary

This opt-in workflow performs actual writes to newly created synthetic files. Report-only Runtime Guard authority permits the report file and denies the protected file. A separate read-only verifier checks disk bytes and captured history. Model output cannot supply a filesystem path or executable code. The default run is offline. An existing local Ollama model can be selected explicitly using the documented options; installing this package starts no model.

Versioned instructions and limits explain the guarded/ablated fixed control separately from model observations. Permission enforcement and correctness of the generated report are different measurements. This is not an arbitrary tool executor or a hostile-code sandbox.

This version also includes ControlledFileSession, a narrow fresh-fixture hook for trusted applications to submit proposal bytes through the same boundary. An optional repository example connects that hook to a Pydantic AI tool callback; Pydantic AI is not a base dependency. The application owns context, labels and files, and the model supplies only proposal text. Storage failures retain an incomplete directory for inspection; they do not undo earlier completed writes.

Save a configured text document

The guarded workspace writer lets a trusted host configure an output directory and aliases for new UTF-8 files. An agent proposes write_text with an alias and document content. The host's deterministic Runtime Guard decides whether the proposal may create that file. The create-only writer reads back the output and records content-free intent and result receipts; an existing file is preserved.

Use WorkspacePolicy and GuardedWorkspace as an application tool, or the installed ash workspace-check, ash workspace-write and ash workspace-verify commands. The optional ash workspace-run --execute makes one request to an existing local Ollama service. No model call is needed for the Guard decision. The host owns paths, policy and classification; proposed text cannot select arbitrary paths or label its own sensitivity. This in-process tool is not an OS sandbox or a semantic checker of the saved document.

Run separate document jobs

The document workflow adds host configuration, a no-effect preview, an explicit one-generation job, read-only status and an optional Pydantic AI bridge. A later job may use a verified previous output as untrusted source text, never as inherited authority. The host still chooses the output policy and any exact JSON or checklist requirements. Quality status describes only declared deterministic checks; even checked does not certify meaning or factual accuracy. An invalid-format document remains saved as a draft but is not reusable as a chain input.

This version also binds document generation to a host-selected content-only tool: model text cannot choose an output alias, path or authority. Reusing a review-required document needs an exact-byte host review digest; a failed quality check still blocks reuse. Hosts can bind input restrictions to source bytes and original expiry times, including bounded multi-source composition. Fixed plans and dynamic admissions declare expected jobs and pending choices; coverage reports whether declared history is accounted for, not whether the documents are factually right. Optional supervised execution may fence an interrupted owned child and permit exact reviewed bytes as data for a new job; the original job remains unresolved and cannot be replayed. No base model-framework dependency, arbitrary-path tool or OS sandbox is added. The versioned operator and replay guide separates scripted transport, real-model use and human review.

Other included surfaces

  • Portable trace validation, scorecards and deterministic comparison reports.
  • Retained ancestry admission and the closed synthetic Runtime Gateway.
  • An experimental single-plan garak adapter, not an official NVIDIA integration or support for every garak detector.
  • Separately versioned optional Transfer, Handoff, Playbooks, Router and Filter packages. Installation does not automatically activate them.

Evidence and scope

The earlier eight-call observation is historical, and this version does not turn it into a new package-specific security-effectiveness claim. The historical eight-call observation used a specific installed 1.9.0 candidate: four protected proposals were denied, four reports were written, and two reports were correct. It is not a measurement of this version or a reliability estimate.

A separate six-call local Qwen2.5 1.5B integration observation for this hook wrote four reports, of which two had correct counts, and denied two protected writes. The eight fixed seed cases and separate offline timing runs are different evidence classes. None establishes cross-model reliability or production containment.

Historical observation and methodology separate controlled evidence from broader claims. Production-wide containment, arbitrary host protection and independent human review are not established.

Author: Dmitry Krivonosov (krivonosoff161). Questions and reproducible reports: GitHub issues.

Metadata

Release files for agentic-security-harness 1.13.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for agentic-security-harness 1.13.1
File Size Uploaded
agentic_security_harness-1.13.1.tar.gz 1.0 MB Details

Built distribution (wheel)

Table of built distributions (wheels) for agentic-security-harness 1.13.1
File Interpreter ABI Platform
agentic_security_harness-1.13.1-py3-none-any.whl Python 3 none any Details

Total release size: 1.7 MB

Release files / agentic_security_harness-1.13.1.tar.gz

Download URL agentic_security_harness-1.13.1.tar.gz
Size 1.0 MB
Tags Source
SHA-256 checksum
How to use checksums
8866b0019351cd0830422187b93f075f9a5d463160ad8d8cecd12af5ad11e657
BLAKE2b-256 checksum
How to use checksums
d04fef73c3ece05a7b7d6ecd15ed4a6a2397cd948a40f921867ea801ab7a19a2
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 9, 2026.

Transparency log

Release files / agentic_security_harness-1.13.1-py3-none-any.whl

Download URL agentic_security_harness-1.13.1-py3-none-any.whl
Size 719.8 kB
Tags Python 3
SHA-256 checksum
How to use checksums
146a782362e0689c80817f733feb63a0c02bfe6a3485ea50946cfc90bdba6f5a
BLAKE2b-256 checksum
How to use checksums
768ddf977f23b60c63a1e4dc768bcb51b048819795eb6f5b95388d10f93cc134
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 9, 2026.

Transparency log

Release history Release notifications | RSS feed

1.14.1

2 release files

1.14.0

2 release files

This release

1.13.1 This release

2 release files

1.9.1

2 release files

1.9.0

2 release files

1.8.0

2 release files

1.7.1

2 release files

1.7.0

2 release files

1.6.0

2 release files

1.5.1

2 release files

1.5.0

2 release files

1.4.0

2 release files

1.3.0

2 release files

1.2.0

2 release files

1.1.0

2 release files

1.0.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page