Authentication tells you who is calling—not what they may do. Axynd connects an agent’s identity and delegated authority to an exact action, leaves the final decision with the receiving system, and records independently verifiable evidence.
Early access · design partners only. What is proven, and what is not
On September 25, 2026 UTC, a developer-run SAP S/4HANA 2025 CAL validation released one existing blocked supplier invoice through Axynd’s signed approval and separate Resume path. The successful attempt sent one Release POST, returned HTTP 200 with Success=true, and produced an Axynd-signed audit that verified locally.
A signed request bound the invoice, fiscal year, gross amount, currency and action.
An explicit confirmation became a signed approval. Approval alone made no SAP write.
A separate signed Resume released execution. After a preflight check of the bounded target, the adapter sent one Release POST.
SAP returned HTTP 200 with Success=true. The Axynd-signed receipt and audit verified locally.
Scope: local test signing identities and locally assigned approval roles, not an external identity provider or a separately authenticated finance approver. This was not customer-environment validation, production certification, SAP-signed evidence or a full procure-to-pay validation. No payment, clearing or evidence attachment was performed. The owner subsequently reported no MRBR match across three blocking selections; that is owner-reported follow-up, not an automated read-back. The SAP S/4HANA Cloud Public Edition adapter remains contract-tested; Cloud Public Edition test-tenant validation remains pending.
A separate invoice-exception settlement reference binds versioned terms to an exact action. It is not part of this live SAP result.
When an agent requests access to another team’s or organization’s system, a valid identity is only the beginning. The receiver still needs to know who delegated authority, what that authority covers, and whether this exact action is allowed.
Axynd brings those checks together at the configured execution boundary. The receiving organization chooses which issuers to trust, applies its own policy, and retains control of execution. An issuer cannot authorize itself into another organization’s system.
Axynd complements existing identity providers, gateways and systems of record; it does not replace them. Partner-specific identity integration and operational controls remain pilot work, not turnkey integrations.
Four questions connect an agent’s identity to a specific request—without turning authentication into automatic permission.
Who is acting, and on whose behalf?
In the transaction reference path, an Agent Passport binds the agent and its key to an issuing organization. The receiver verifies that binding against its configured trust—not an agent’s self-asserted name.
What permission does the agent carry?
A signed Authority Grant limits what the agent may request, for which purpose and validity window. The exact action must fit that delegation; a request cannot give itself broader authority.
Will the receiving system allow it?
The system owner supplies trusted issuers and exact expectations, then applies local policy. It may allow, deny, or require approval. Approval cannot widen the agent’s delegated authority.
What decisions and outcomes were recorded?
Signed records bind the request, authority, decision and reported outcome. A reviewer can check supported evidence offline with the private standalone verifier and reviewer-supplied trust.
Trust is a decision, not a badge. A signature authenticates a recorded statement; it does not establish the issuer’s reputation or the truth of a business claim. The receiver decides what to trust and what to permit.
Prototype scope: these are implemented reference paths, not production identity federation or a universal agent credential. Signed evidence does not independently prove physical location, hardware trust or absence of bypass. Review verification limits.
One workspace connects agent enrollment, reviewed permissions and per-agent activity. Follow an exact request from delegated authority to the receiving system’s decision and recorded outcome.
Check a configured workload identity and possession of the registered signing key. The accountable owner stays administrator-asserted, not independently verified.
Review the action, target, amount and expiry before issuing a grant. Revoke an individual grant or suspend the agent; configured receivers enforce the recorded limits.
When policy requires approval, an approver records a decision. A separately authorized Resume releases execution. Approval alone does not write to the protected system.
Inspect per-agent activity and readable trust reports. Download the original signed audit for independent verification; the readable report is not itself signed.
Control at the configured receiver: managed limits and revocation depend on its connected authority registry. Suspension and revocation stop future dispatch admission; they cannot cancel already-admitted work or undo completed actions.
Locally validated, not production-qualified: this connected workflow uses a signed synthetic identity fixture and mock ERP. It is not a new live Auth0 or SAP test. Live-tenant enrollment and production lifecycle operations remain qualification work.
In the business-action reference path, a signed approval changes lifecycle state only; it makes no protected-system write. Only a separately authorized Resume releases that exact transaction.
If the outcome of a dispatched write is ambiguous, the transaction becomes EXECUTION_UNKNOWN. Axynd does not blindly retry an uncertain write. The request, decision, approval, Resume and reported outcome are recorded as signed evidence.
The same authority and evidence model has a separate application to AI inference, where customer policy limits which runtime may execute an invocation. Its controls and validation limits are distinct. Review policy-bound inference
Working prototype with bounded local validation; seeking enterprise design partners.
The results below test specific identity, authorization and evidence paths. They do not establish a production identity service, universal agent trust, or an independently audited enterprise deployment.
Single host; one synthetic one-token Gemma round every 30 minutes, September 2026. Measured prototype evidence, not a production SLO or representative load.
Auth0-backed Gemma qualification: an initial developer-run boundary pilot passed on September 13, 2026, followed by a single-host 24-hour qualification completed on September 17, 2026 after 86,401 measured seconds. Using one Auth0 dev application identity, 48 synthetic one-token gemma3:1b workload rounds completed under Axynd delegation and execution-policy checks. All 48 preflights, 48 resource samples and 48 offline evidence verifications passed; both controlled expiry, restart and recovery exercises passed, services stopped cleanly, and zero gateway exception markers were recorded. The run completed 383 logical public-key refreshes from 383 attempts with zero transient failures, so the bounded retry path was not exercised. Earlier boundary tests rejected cross-customer access, model changes and replay, including replay after restart, and separate bounded container-network checks passed. What this run does not show: a live Auth0 outage or signing-key rotation, customer acceptance, an independent audit, a production SLO, representative load, continuous network or hardware attestation, distinct physical locations, or production tenant isolation. Review the identity integration and test limits.
Separate SaaS validation: a two-customer synthetic demo uses in-process HTTP and fake provider transports. Bounded tests cover authenticated customer binding, separate customer keys and state, cross-customer decision rejection, and replay protection. Both demo execution bundles pass customer-aware offline review. This is not a live customer deployment or a real inference run. Its entry point offers simulation-only policy preview; it does not issue signed placement plans or automate recovery.
Local SaaS runtime validation: a separate developer-run acceptance passed on September 13, 2026 UTC (September 12 locally). Two synthetic customers completed one-token invocations against a real local Ollama model over loopback HTTP. Cross-customer access, altered invocations and replay were rejected; both saved execution bundles passed customer-aware offline verification in separate processes. A relay-injected failure produced no call to the secondary tripwire. This was not a model outage, automatic recovery, independent evaluation or customer deployment. Review the validation limits.
Live experiment scope: the recovery run on September 12, 2026 used a preloaded small model and a synthetic one-token invocation across two Kind clusters on one host. This demonstrates logical separation, not distinct physical regions, representative performance or customer validation.
Controlled recovery: signed placement plans used registered attributes and reported runtime health. The separate experiment exercised primary execution, an outage, rejection of an unauthorized target, explicit replanning, and authorized secondary execution. Both successful execution evidence bundles verified with the standalone offline verifier. This does not establish automatic failover.
Pick one consequential action an AI agent could take in your system of record, such as releasing a blocked supplier invoice, that you would not allow today. Bring its system owner, an engineering owner, a security reviewer and a non-production environment. We’ll define the exact authority, the approval and execution path, the allowed and denied cases, and the evidence your reviewers need.
Start with a discovery conversation. Agree on integration effort, performance expectations and acceptance criteria before a bounded pilot.