AIFW v1.1.264 - The Goose

AIFW 1.1.264

Released: 2026-09-28
Edition: Community and Enterprise GA
Runtime: ASP.NET Core on .NET 11 RC1 (11.0.0-rc.1.26425.128)

AIFW is the AI governance and agent-trust gateway from Securetron: policy enforcement, prompt and
response inspection, routing, identity validation and audit for generative-AI traffic, without
locking you to a model provider.

Highlights

• Chain of Command — agents have owners. Ownership, delegation and swarm command ship as a
  complete, verifiable layer, with cryptographically signed command vouchers.
• Compliance module — tells you which technical controls this installation can prove, and which
  it cannot, across ten regulatory and standards frameworks.
• Semantic flag scores in the audit log — every scan now records how close it came, not only
  whether it fired.
• Rebuilt semantic rule base — the shipped built-in rules are the ones that were measured, with
  per-rule exemplars.
• Inspection fixes — verification verdicts attach to the exact request, blocks are judged by the
  block threshold, and stream cancellation after a confirmed verdict behaves.

Container images

Registry	Image	Tags
GitHub Container Registry	ghcr.io/securetron-gh/aifw	1.1.264, latest
Docker Hub	securetron/aifw	1.1.264, latest

• linux/amd64, 859 MB.
• Runs as non-root user app; HTTP 80, HTTPS 443 (Endpoints:WebHttps).
• Image digest: sha256:bc539233998f70fc4971c39fd87dc8b731c034dcd61ea3d87c69066384fad500

docker run --rm -p 8080:80 \
  -e ConnectionStrings__PostgreSQL="Host=<host>;Port=5432;Database=pki_remote_agent;Username=<user>;Password=<pass>" \
  -e AiFw__JwtSecret="<secret>" \
  ghcr.io/securetron-gh/aifw:1.1.264

Health: GET /api/health · A2A discovery: GET /.well-known/agent-card.json

Chain of Command

Agents now have owners, and authorization checks run owner-first, before identity chaining.

Ownership and delegation

• Every credential resolves to an owner through one resolver — credential mapping, then the registry,
  then anonymous. An IP address is never treated as an identity.
• Ownership can be claimed with sponsor codes: stored hashed, single-use by default, optionally
  multi-use, and revocable. Redemption works only for an unclaimed agent or one already owned by the
  redeeming owner.
• Agents can be transferred, and delegations are bounded by a configurable depth that is enforced on
  the owner-first path.
• The owner-first mode is off by default (identity_policy_owner_enforced) and takes effect only
  when A2A authentication is on (a2a_auth_mode=on). With it off, behaviour is unchanged.

Swarms

• Swarm model and membership, authority wiring, and orders that fan out through the standard task
  rails and are idempotent.
• Consents expire; sensitive hub capabilities and hub revocation cascades are queued for approval
  rather than applied directly; swarm member reads are scoped to consent and capability.
• A per-swarm lifecycle cascade, and swarm legs recorded for revocation, authorization callbacks and
  duplicate suppression.

Command vouchers

• A signing substrate for command vouchers, a published trust anchor for offline verification, and
  verification of a sub-agent's signed result report before it is believed.
• Issuer kid, rotation overlap and a revocation list. The voucher signing key is never the TLS or
  web certificate key; it can be provider-supplied and replaced by an HSM/KMS implementation without
  changing the voucher format.

Visibility

• The audit log records the actor's standing and the swarm order in force.
• Admin agent views gain a swarm topology diagram, a commander badge, and a swarm health card.
• GET /agent/status exposes a versioned commander and skill view.
• Asserted agent aliases are stored and shown in the audit pop-up.

Hardening

• MCP now requires authentication by default and attributes each call to the credential.
• Agent-facing surfaces accept agent API keys; API key scope is enforced, so a registration-only
  key can enrol and claim and nothing else.
• Expired keys and delegation grants are retired on a schedule.

SDKs and documentation

• .NET, Python and TypeScript/Node clients for the Chain of Command protocol.
• Full operator and developer guide in docs/chain-of-command.md.

Compliance module

Answers one question about an installation: which technical controls can it prove, and which can it
not. It reads what the rules engine is configured to do and records the result as evidence. It is a
verification plane — it never sits in the request path and never enforces.

• Framework catalogue and assessment engine, seeded on startup: 10 frameworks, 116 controls,
  161 checks, 51 rule templates, with per-framework guides in compliance/.
• Posture page at /Compliance with frameworks under management, controls assessed, open gaps and
  a posture score, filterable by framework, status, severity and mandatory controls.
• Control → rule linking with rule templates: the module creates a rule in the shape the control
  expects and links it, so compliance-driven rules are not hand-built.
• Drift reporting when a linked rule changes, naming the control, the rule and the actor.
• Evidence packs with a verifiable manifest, in JSON and CSV, retained beyond the run that produced
  them with retention-based purging; scheduled assessments and reports.
• Manual attestations — a named human, a timestamp and an expiry, recorded and withdrawable — for
  the controls no machine can prove.
• Identity-scoped controls report attribution coverage, so a credential type that carries traffic
  without attributing it is visible as a gap.

The module is off by default (ai_fw_compliance_enabled). With it off there is no navigation
entry, no scheduled work and no tables written.

Semantic flag scoring in the audit logs

Previously the audit recorded that a prompt was blocked, but not by how much or on what evidence.

• Every scan now records its flag score, including prompts that were not flagged — so a request
  that came close is visible rather than invisible.
• Blocked rows carry the verification score as well, on both the request and the response entry.
• Verification verdicts attach to the exact request they belong to, via a correlation id, instead
  of being matched by time window.
• Flag-verification blocks are judged by the block threshold (separate from the detection
  threshold) and always recorded.
• Both scores are shown in the audit log detail view at /AiFw/AuditLogs.

Semantic rule base

• The built-in rules were rebuilt from the tuned set: eight semantic rules plus PII Masking. A
  fresh database now seeds the rules that were actually measured, rather than an older set. Rules live
  in the database; changing built-ins affects new databases only.
• Configurable exemplars per rule — example phrasings carried on the rule itself, with a
  preference for configured exemplars over the built-in seeds.
• Block before the answer when verification is on, so a confirmed violation is stopped before any
  model output is returned.
• Fail-closed verdicts with a bounded failure mode, and a distinct
  semantic_verify_unavailable code so a verification outage is never mistaken for a detection.

Measured on the 726-case buried-injection corpus: 574 of 629 attacks blocked (91.3%) with
0 of 97 legitimate prompts refused (0%). This is measured against https://github.com/ethz-spylab/agentdojo and https://github.com/rudratoshs/buried-injections

Inspection and verification fixes

• Fixed async flag-verification persistence and cancellation, including cancellation of an active
  stream after a confirmed verdict.
• Removed a nested form in the Semantic Analysis settings that broke submission.
• Repaired the Allowed Auth Methods form and tidied the Compliance tab.
• The chat model and endpoint rows now appear when flag verification is enabled, rather than only for
  the chat backend.
• The Guardrails model path control is hidden where it does not apply.

Also in this release

• Risk dashboard performance — reads now come from a daily rollup instead of repeated scans of the
  raw history, and the history read is no longer issued three times per page load.
• Audit — the real source of a request is recorded, and the retention purge is itself audited.
• Company quota ledger and licensing unaffected; no schema-breaking changes.

Upgrading

• New tables are created by idempotent DDL on startup, so an existing database picks up the Chain
  of Command and Compliance tables without a migration step.
• Chain of Command ownership enforcement and the Compliance module are off by default. Both are
  opt-in, and enabling either does not change enforcement behaviour for traffic that was already
  being scanned.
• Existing rule rows are untouched by the upgrade. The rebuilt built-in rule set applies when the
  rules table is seeded — that is, on a new database.