Release history

Agent limits per plan are enforced, suspended agents can be reactivated, and the viewer role is read-only for agents.

• Behaviour change — each plan's active-agent limit is enforced: sandbox 2, Starter 5, Growth 50; Enterprise by contract. Registering an agent, enrolling a discovered agent, ignoring an active discovered agent or reactivating an agent at the limit is refused with 403 AGENT_LIMIT_REACHED (details: limit, counted); the sandbox keeps its existing FORBIDDEN response. Discovered agents awaiting enrolment are not counted; ignored agents are. Suspending or retiring an agent frees its place. An organisation already above its limit keeps its agents and cannot add more until it is below the limit.API
• New: POST /v1/agents/{agent_id}/reactivate returns a suspended agent to active, including one suspended automatically by behaviour monitoring, on every plan. It requires an organisation owner or admin (not an API key) and counts against the plan's agent limit. A retired agent cannot be reactivated. The dashboard shows Reactivate on a suspended agent.NewAPI
• Behaviour change — enrolling a discovered agent no longer changes its status: enrolling one that is suspended or retired is refused with 409 AGENT_NOT_ACTIVE; reactivate it first (retired agents stay retired).API
• The viewer role is read-only for agents: registering, updating, suspending, retiring or reactivating an agent, changing its key, and submitting, enrolling or ignoring a discovered agent answer 403 VIEWER_ROLE_READ_ONLY for a viewer. Owners, admins, custom roles and API keys are unaffected.SecurityAPI
• A decision whose acting agent cannot be looked up is now DENY (discovery:agent_unavailable) instead of continuing.Security
• A runbook's suspend-agent step acts only on an agent of the runbook's own organisation.Security

Structured-rule policies for Starter, higher plan volumes, and reliability fixes.

• New: Starter organisations can create structured-rule policies in the dashboard (an action, an optional amount condition, and an outcome of allow, review or deny), try them with a dry run, and activate them. New Starter organisations are policy-required: until a policy is active, decisions that need AXIS are DENY with error_code POLICY_REQUIRED. Existing organisations are unchanged.New
• Plan volumes: Starter 50,000 and Growth 500,000 authorization decisions per month; the sandbox trial 5,000.Improved
• Fix: delegation tokens now get a few seconds of clock tolerance on iat and exp; before, a client clock even a moment ahead of ours could be refused FUTURE_DATED.Fix
• Fix: a background behaviour scan could briefly delay API responses under load; it now runs without blocking request handling.Fix
• Dashboard: a click made immediately after a page loads is no longer ignored, and moving quickly between pages no longer risks a temporary sign-out.Fix

Policy changes are re-enabled.

• Policy changes are re-enabled (2026-10-15): creating a policy with a review record, activating, rolling back, canarying, attaching, detaching or deleting a policy, and choosing a federation policy no longer answer POLICY_CHANGES_SUSPENDED. Policy-selection changes require an operation_id and an expected_version. Runtime policy slots use GET /v1/policies/slots and require policies.select; choosing a federation policy requires federation.policy.manage. API keys cannot perform these changes. Creation and deletion retain their endpoint-specific requirements. Plan limits still apply. No new runtime version was deployed.ImprovedAPI

Policy isolation and version pinning, per-organisation federation policies, and stricter issuer checks. Policy changes remain temporarily suspended.

• Policy changes remain temporarily suspended (since 2026-10-05): creating a policy with a review record, activating, rolling back, canarying, attaching, detaching or deleting a policy, and choosing a federation policy are suspended and answer POLICY_CHANGES_SUSPENDED; authentication, permission or plan checks may refuse a request first. Policies already in force are unaffected. The features below that change policies are deployed and become usable when policy changes are re-enabled; we will announce that here.Security
• Isolated, immutable policy revisions: each policy is validated when it is created and evaluated only as its own immutable revision, scoped to your organisation. If the policy engine cannot evaluate a configured policy, the decision is DENY with the reason recorded; it never falls back to a placeholder evaluator.ImprovedSecurity
• Evaluation provenance: signed decisions now record how the policy was evaluated (the evaluator, the outcome status, and the revision and module hash that were evaluated), so a verifier can tell an evaluated policy from one that failed or was never reached.NewSecurity
• Behaviour change — a requested policy_version on POST /v1/decide is now a pin evaluated in addition to your organisation's policy, never instead of it. A version in the request body is honoured only for a caller with the policies.pin permission, which API keys never hold; otherwise the decision is DENY with error_code POLICY_VERSION_UNAUTHORIZED. A version claimed in the root delegation token counts only when that token is signed by one of your organisation's designated pinning-authority keys. Responses report policy_version_requested and policy_version_applied when a pin outcome is determined.APISecurity
• Stricter issuer checks: every token in a delegation chain must be issued by a registered identity, and must verify with one of that identity's registered keys; the chain's root decides which issuers your organisation may trust. Failures are DENY decisions with a specific error_code. The same checks apply to offline-decision sync, Trust Summary issuance and proof retrieval. Some early denials, such as a malformed chain, are returned before a signed decision artifact is created or persisted: the response is a DENY with an empty artifact_id.SecurityAPI
• Federation: each organisation now chooses its own policy for a peering with PUT /v1/federation/{trust_id}/selection; it is evaluated in addition to the organisation's own policy, deny-overrides. The shared peering policy (PATCH /v1/federation/{trust_id}/policy) is removed.NewAPI
• Behaviour change — policy-change requests (activate, rollback, canary, attach, detach) now carry an operation_id and the expected_version read from GET /v1/policies/slots, and need the policies.select permission (organisation owners and admins); API keys are refused. Attaching or canarying a policy now needs the same review as activating it. Refusals have specific error codes.API
• An invalid API key on POST /v1/decide returns 401, as on other endpoints. While the service starts, /v1/decide may answer 503 POLICY_ENGINE_NOT_READY with Retry-After.API
• Agent registration refuses DIDs that are reserved for organisation identities or the platform, or that already name an organisation identity, with IDENTITY_NAME_TAKEN; a DID another agent already holds is refused with 409 and error code ERROR.APISecurity
• Dashboard: policy actions follow the new request contract, and a change whose outcome is not yet known stays visible until AXIS confirms it; draft policies offer Open PR; a recertification that was not saved is shown on its row.Improved

agf-sdk 0.9.0 — approved execution from the Python SDK, for direct callers and the MCP gateway.

• agf-sdk 0.9.0 — direct callers can bind the exact call they will make when requesting a decision (decide(binding_sha256=...), with helpers in agf.binding), then use execute_approved() after a human approves it. The action runs only if validation is valid for that decision and claims that approval within its signed window; each call invokes the action at most once and attempts at most one outcome report, and nothing is retried.NewSDK
• execute_approved() returns the report's status — recorded, accepted without receipt, rejected, or uncertain — so a report that failed or whose result is unknown is visible to the caller, alongside the action's own result or error.NewSDK
• MCP: a call that needed review can be re-presented after approval with MCPGatewayClient.execute_approved(). The request is resent byte for byte as it was reviewed; if the gateway, credentials or MCP session differ, nothing is sent and the change needs a new review.NewSDK
• Runtime approval-error codes raise AGFApprovalExecutionError (for example APPROVAL_CONSUMED, which must not be retried). Generic HTTP failures now use AGFHTTPError, which remains an AGFError subclass. Supplying binding_sha256 bypasses the SDK's local decision cache, so these decisions have no offline fallback.ImprovedSDKAPI
• Limits for direct callers are unchanged: AXIS does not perform or observe a direct caller's call, so the binding is the caller's attestation of what it sends and the outcome report is its claim, not an observation.SecuritySDK

Approved execution — a REVIEW_REQUIRED decision approved by a human can now be used, once, for the call that was reviewed.

• Approved execution: after a REVIEW_REQUIRED decision is approved, the same decision can be executed by the caller that requested it — no new decision is made. Through the HTTP, MCP and A2A gateway proxies, resend the reviewed call with the X-AGF-Approval header set to the approval request ID. Direct callers send the approval request ID and the call's binding_sha256 to POST /v1/decisions/{artifact_id}/validate-execution.NewAPISecurity
• Exactly the reviewed call: the decision records a binding of the request (destination, query, every forwarded header in order including repeated ones, credential and payload bytes). If anything differs at execution time, the call is rejected with APPROVAL_REQUEST_MISMATCH and, through a gateway, nothing is sent. For a direct caller, AXIS compares the binding digest the caller supplies; it cannot check the call the caller then makes. Gateways set their own fixed values for the headers an HTTP client would otherwise add by default.NewSecurity
• One use per approval: each approval can be claimed once. The claim is made atomically, and a second attempt is rejected with APPROVAL_CONSUMED, even if the first attempt failed. Through the AXIS gateway proxies, this means at most one dispatch: the claim is made before anything is sent, and the gateway makes a single upstream attempt, with no retries and redirects not followed.NewSecurity
• Signed execution window: an approval can be executed only until a time signed into its approval evidence (default one hour after the outcome, configurable per organisation up to 24 hours). Through the AXIS gateway proxies, the window is checked again immediately before sending, and a dispatch more than 5 seconds after its validation is refused. Validation for a direct caller is refused once the window has passed.NewSecurity
• Only signed evidence authorises execution: the approval request, its signed outcome and the decision's signature are checked — never a stored status. If the execution-time validation cannot be signed and stored, it fails and the approval is not claimed. A timeout that continues under an organisation policy is executable under the same rules, and is still recorded as a policy continuation, not a human approval.Security
• Approval outcomes are now signed in evidence format 1.1, which adds the execution deadline (execution_not_after: set for approved and policy-continued outcomes, null otherwise). Records in format 1.0 remain valid evidence but cannot authorise execution.ImprovedAPI
• Audit verification for approved decisions: signed evidence establishes approval before the execution validation, within the signed window; the receipt reports the execution. New violations: EXECUTED_MORE_THAN_APPROVED (more than one verified executed receipt for one decision; verification cannot prove the receipts it sees are complete) and EXECUTION_VALIDATION_AFTER_APPROVAL_EXPIRY. A denied or timed-out approval followed by execution is still EXECUTED_WITHOUT_APPROVAL.ImprovedAPI
• Direct-caller limits: a direct caller gets one claim and one accepted outcome report. AXIS does not perform a direct caller's call, so it cannot enforce how many times that caller dispatches it, or when. The approval is consumed when validation succeeds, and the self-reported outcome is a claim, not an observation. If issuing the report's receipt fails, the report still counts as used.Security
• Behaviour change: validate-execution and report-outcome previously rejected every REVIEW_REQUIRED decision. They now handle an approved one under these rules: validation needs approval_request_id and binding_sha256, and a report needs a claimed validation and is accepted once. ALLOW decisions are unchanged.API
• Decisions made before this release carry no request binding and cannot be executed; an approved one must be requested again. Approving a decision is never, on its own, permission to act — only a successful execution-time validation of the exact reviewed call is.Security

Signed evidence for approvals, revocations and execution-time checks — verifiable without trusting stored records.

• Human review requests and their final outcomes (approved, denied, timed out) are now recorded as signed evidence, bound to each other and to the decision under review. A timeout that continues without a human is recorded as exactly that, never as an approval.NewSecurity
• Every revocation, including each token cut by a branch revocation and automated revocations from deployment gates, runbooks and drift response, is recorded as signed evidence naming who or what revoked it. If evidence cannot be signed, the revocation still takes effect and the record is marked unsigned.NewSecurity
• Execution-time validation results are now signed.ImprovedSecurity
• Audit verification evaluates only signed evidence and reports each check as verified, violation, not established or not applicable. Evidence that is missing, unsigned, erased or malformed is reported as not established, never as clean — so records created before this release report not established.ImprovedAPI
• New read endpoints for signed evidence: approval records, revocation records, and signed execution-validation records.NewAPI
• Erasure now covers signed evidence. Erasing a decision or an agent, or — new — a user named as requester, approver or revoker, erases the signed records that name them. The fact that a token was revoked is kept, so revocations stay in force. Erased evidence is reported as unavailable.NewAPISecurity
• Known limitation: AXIS records signed approval evidence, but does not currently provide a way to execute an approved REVIEW_REQUIRED decision — approved decisions remain blocked. A clean end-to-end approval result is therefore not reachable yet; an approved-execution path is planned separately.Security

Published signing keys — decisions and receipts can be checked against AXIS's public key set.

• AXIS now publishes the public keys it signs with at https://pdp.intrexa.in/.well-known/jwks.json, with each key's status and, where it is known, its validity window. Retired keys stay published, so evidence signed before a key change can still be checked.NewAPISecurity
• New decision artifacts, execution receipts and decision records (ADRs) name the key that signed them (its key-set kid), so a verifier picks the right key after a rotation. Trust summaries, override tokens and platform-issued delegation tokens keep their existing identifiers; for those, the key is selected by issue time.ImprovedSecurity
• The signing identity is now https://pdp.intrexa.in. Evidence signed under the previous identity, https://pdp.agentgovernancefoundation.com, still verifies: that origin's key-set address redirects once to the new one, and the new key set lists it as a previous signer. This checks the keys as those origins serve them today; it is not a record of what was published when the evidence was signed.Security
• Key changes are explicit operator actions. In production the service will not start — and a deploy will not restart it — unless its signing key is the active published key.Security

Live dry-run and policy evaluation explainability — see what a decision would be, and why, without enforcing it.

• Live dry-run: send dry_run: true to POST /v1/decide to evaluate a request against your active policy and real identity and delegation state with no side effects — no audit artifact, no quota use, no human-review request, no webhook. The response is marked simulated: true and carries an empty artifact_id.NewAPI
• Evaluation explainability: policy dry-runs and live dry-runs can return explain, the policy engine's own evaluation trace. It is never fabricated — when the engine cannot produce a trace, explain is null.NewAPI
• Dashboard: a dry-run toggle with a simulated badge in the decision tester, and a dry-run panel with an evaluation-trace viewer on each policy's page.New
• agf-sdk 0.8.0 — AGFClient.decide(dry_run=True) and dry_run_policy(), also on SyncAGFClient. A dry run never raises a denied or review-required error, never falls back to the offline cache and never writes to it.NewSDK
• Candidate-policy dry-runs and backtests now evaluate the candidate policy itself. Previously, when the policy engine was reachable, they could evaluate the policy already loaded instead. The create-policy placeholder now shows the policy shape AXIS actually evaluates.Fix

Execution receipts for direct decide()/validate_execution() callers not routed through an AXIS Gateway proxy.

• New POST /v1/decisions/{artifact_id}/report-outcome endpoint — lets a caller that used decide()/validate_execution() directly self-report its execution outcome, producing a Receipt where previously only Gateway-proxied (MCP/A2A/HTTP) calls ever got one. Marked gateway: "self_reported" in the signed payload so it's distinguishable from a Gateway-observed Receipt.NewAPISecurity
• agf-sdk 0.6.0 — AGFClient.report_outcome()/SyncAGFClient.report_outcome(), plus an opt-in report_outcome=True flag on guard_tool() that reports the outcome automatically right after the guarded function returns or raises.NewSDK

Execution-time authorization re-validation (Spec 30) — closes the gap between decide() and dispatch.

• Execution-time authorization validation (Spec 30) — re-checks platform-halt state, revocation, and expiry immediately before dispatch, closing the window between decide() and actual execution. New POST /v1/decisions/{artifact_id}/validate-execution endpoint. As of 2026-08-15, the built-in HTTP/MCP/A2A gateway proxies run this check by default (opt-out), not just when a caller opts in.NewAPISecurity
• agf-sdk 0.4.0 — AGFClient.validate_execution()/SyncAGFClient.validate_execution(), plus an opt-in validate_execution=True pre-flight flag on the LangChain/CrewAI/MCP guards and AgentGovernance.authorize().NewSDK

Outbound webhooks, JIT credentials, analytics dashboard, access review automation, and Python SDK with LangChain + CrewAI adapters.

• Outbound webhooks — subscribe to decision, approval, and quota events via HMAC-signed HTTP POST. Up to 60 events/min per org.NewAPI
• JIT (just-in-time) credentials — issue ephemeral API keys for agents that expire after a configurable TTL. Keys auto-cleaned by scheduler.NewAPI
• Analytics dashboard — 30-day decision volume chart, outcome breakdown, top agents table, policy effectiveness, and behavior alerts.New
• Behavior detection — scheduler scans audit artifacts every 5 minutes for 4 threat patterns: data exfiltration, privilege escalation, resource hijacking, lateral movement.New
• Access review automation — daily reminders for agents with recertification due in 7 days. Dashboard shows current / due soon / overdue status with one-click recertify.New
• Python SDK (agf-sdk) — AgentGovernance facade, async AGFClient, LangChain gate tool + AGFGuardedTool adapter, CrewAI adapter, webhook signature verification.NewSDK
• TypeScript SDK expanded — webhooks, JIT credentials, analytics, access reviews, and behavior alerts resources added to AGFClient.ImprovedSDK
• Scheduler thread bug fix — all APScheduler jobs now use run_coroutine_threadsafe instead of ensure_future, fixing RuntimeError on first fire.Fix

Human-in-the-loop approvals, tier rename, background scheduler, feature gating, config hardening, and audit isolation.

• HITL approval workflow — REVIEW_REQUIRED decisions create pending approval requests. Dashboard shows pending / approved / denied tabs with inline approve/deny + comments.New
• Approval timeout scheduler — pending requests expire after configurable timeout_seconds. Runs every 5 minutes.New
• Tier rename — basic → starter, growth → growth (unchanged), enterprise unchanged. Quota defaults updated: starter 2,000/mo, growth 15,000/mo.ImprovedAPI
• Feature gating — require_tier() dependency factory gates features by plan. Growth required for suspend/retire, policy CRUD, webhooks, JIT. Enterprise required for compliance and federation.NewAPI
• Background scheduler — APScheduler AsyncIOScheduler wired into app lifespan. Jobs: overage_report and audit_cleanup. Configurable via admin Configuration → Scheduler tab.New
• Audit store per-org isolation — FileAuditStore writes to decisions/{org_id}/YYYY/MM/DD/. Backward-compatible with flat-path artifacts.Improved
• AGF_VERIFIER_ID, ALLOWED_ORIGINS, GIT_AUTHOR_NAME/EMAIL env vars added for deployment hardening.Improved
• Policy VCS — activate policy now requires pr_status='merged' when VCS is enabled.ImprovedAPI

Policy VCS with PR workflow, runbooks, metering and quota system, billing integration, and email notifications.

• Policy version control — policies tracked in a git repo. PR workflow: open, merge, reject. Diff endpoint compares any two SHAs.NewAPI
• Runbooks — define multi-step automated responses to events. CRUD + manual trigger + execution history.NewAPI
• Quota metering — per-org decision quotas with tier defaults. Enforcement at /v1/decide with 429 + Retry-After when over limit.New
• Quota headers — X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset on every 200 response.NewAPI
• Stripe billing integration — subscription lifecycle webhooks, metered overage reporting, provider-switchable (stripe / manual / disabled).New
• Welcome and quota warning emails — fire-and-forget after registration and at 80% / 100% quota threshold crossings.New
• Usage dashboard — QuotaBar, overage banner, history table with Limit and Overage columns.New
• Onboarding checklist on dashboard home — 4-step progress tracker that disappears when complete.New

Admin panel, platform metrics, org impersonation, key rotation UI, federation layer, and security hardening.

• Admin panel — internal ops app for organization, user, and platform management.New
• Org impersonation — admin can open a 15-min impersonation session in the dashboard. Amber banner shown during session.New
• Platform key rotation UI — admin can view Ed25519 key fingerprint, rotate the platform key, and record JWT rotation from the Security page.New
• Federation layer — org registry (DID resolution), peering invitations, accept/reject flow, cross-org policy evaluation.NewAPI
• HybridKeyResolver — resolves keys from local PEM store or remote org registry. Pluggable via KEY_RESOLVER_BACKEND env var.New
• Security hardening — HttpOnly cookie auth flow, AuthProvider + useAuthToken() hook across all 21 client components, CSP headers, HSTS.Security
• Rate limiting tightened — per-endpoint limits: decide 120/min (per-org), auth 5/min, register 30/min, billing 5–10/min.Security
• Per-endpoint slowapi limits added to all sensitive routes.Security

Initial release — PDP, agent identity, delegation chains, trust scoring, audit artifacts, compliance reports, and multi-tenant dashboard.

• POST /v1/decide — real-time policy decisions with trust scoring, risk evaluation, and signed audit artifacts.NewAPI
• Agent identity — DID-based agent registration with Ed25519 key upload. Agents have persistent root identity across invocations.NewAPI
• Delegation chains — JWT chain evaluation. Each hop is verified; chain depth is tracked in audit artifacts.NewAPI
• OPA policy engine — Rego policy evaluation. Policies versioned, activatable. Python fallback engine available.New
• Compliance reports — NIST AI RMF, EU AI Act, and ISO 42001 coverage. Exportable via dashboard and API.NewAPI
• Multi-tenant — organizations, users, team invites, role-based access (admin / member). Per-org API keys.New
• Dashboard — 25-page Next.js app. Agents, policies, audit log, compliance, delegations, team, usage, settings.New
• TypeScript SDK (@agf/sdk) — AGFClient with decide, agents, and audit resources.NewSDK
• Deployment files — nginx virtual host, systemd service units, .env.example for all settings.New