01 · Identity
Who is acting?
An Agent Passport binds an agent identity and key to an issuing organization. The receiver checks that binding against its own trusted issuers and keys.
Reference architecture · Authority for agent actions
Agent identity is the start. Trust is a receiving-side decision.
Before an AI agent’s request changes a system of record, Axynd checks who is acting, what authority it carries and whether the receiving organization’s own policy allows this exact action, then records signed evidence a reviewer can independently check.
Axynd complements existing identity providers, gateways and systems of record. Authenticating an application or person does not authorize every agent action: the receiving organization chooses trusted issuers and keys, checks exact expectations, and retains the final decision.
Working prototype with bounded local validation; seeking enterprise design partners. A signature is not a reputation score or proof that a business claim is true. Trust onboarding and integration remain deployment-specific; production identity federation, managed identity lifecycle and turnkey IdP coverage are not established.
The trust foundation
Four questions before an agent request becomes an action.
The reference business-action path separates identity, delegated authority, the receiver’s decision and evidence. Each has a different job; none substitutes for the others.
02 · Authority
What can they request?
An Authority Grant constrains delegated actions, resources, counterparties, purpose and validity. The signed request binds that authority to an exact transaction.
03 · Receiving-side trust
Will the receiver allow it?
The receiving organization verifies the artifacts and exact expectations, then applies its own policy. Identity and delegation are inputs, not automatic permission to execute.
04 · Evidence
What was recorded?
Signed records connect the request, policy decision and reported outcome. A reviewer supplies trust and expectations to check the evidence independently.
Reference artifacts, not universal credentials: an Agent Passport and Authority Grant are not automatically accepted by every destination. Counterparties still need trust onboarding and shared semantics. The current transaction reference topology uses two Axynd gateways; the standalone verifier remains in private invited evaluation.
Current prototype capabilities and planned deployment boundaries
Current prototype: transaction gateways; a connected local agent trust workspace for workload-and-key enrollment, bounded authority, per-agent activity and audit-backed reports; a customer-hosted trusted-execution control plane with inference workloads, runtime-health inventory, signed placement plans, and edge enforcement; a private offline verifier preview with one completed independent blind evaluation; A2A and MCP paths; a versioned P2P invoice-exception settlement binding; a contract-tested SAP S/4HANA® Cloud Public Edition reference adapter and a separate developer-run SAP S/4HANA 2025 CAL invoice release; and signed service-identity and evidence-deposit receipts issued only after exact native-record read-back. A managed multi-tenant service and production packaging are planned.
Connected agent trust workspace
Enroll an agent. Bound its authority. Review what it did.
The connected prototype brings enrollment, issued authority, per-agent activity and readable evidence into one operator workflow. Registering an agent does not verify its identity, and issuing authority does not approve or execute an action.
01 · Enroll
Verify the workload and its key.
Enrollment checks a workload token against configured identity-provider trust and requires a single-use challenge signed by the registered agent key. An operator session alone cannot complete enrollment. The accountable owner remains an administrator assertion, not an identity-provider-verified person.
02 · Bound authority
Issue, revoke or suspend.
Issue time-limited authority for an exact action, transaction, resource, counterparty and currency. The connected receiver enforces the recorded hard maximum separately from the autonomous approval threshold. Revoke a grant or suspend an agent to stop future dispatch admission at configured receivers.
03 · Follow activity
Keep approval separate from execution.
Follow an agent’s transactions into the existing approval inbox. Scoped roles separate administration, finance approval, execution Resume and review. Approval alone makes no protected-system write. Completed evidence stays available after suspension; replaying a completed transaction returns its recorded result, not a new execution.
04 · Review evidence
Readable reports. Original signed audits.
A report explains the agent and delegator, exact action, decision, approval, explicit Resume and reported outcome from a verified audit. The readable HTML is unsigned; the original signed audit remains available for independent verification. EXECUTION_UNKNOWN remains uncertain, not a success.
Local validation, not a new live integration: the repeatable connected workflow uses an offline, cryptographically signed Auth0-shaped identity fixture and an in-memory mock ERP through the real Axynd protocol, policy, approval, Resume, journal and audit paths. It makes no outbound network calls. It is not a live Auth0 tenant qualification, another SAP test, customer validation or production deployment.
Identity, enforcement and reporting boundaries
Configured identity: the reusable backend accepts deployment-configured issuer, audience, trusted public keys and client-to-organization mappings. Application credentials establish an application identity, not a unique running process or a human owner. Key refresh and live-tenant qualification remain deployment work; the local fixture is not evidence that those operational controls have been exercised.
Receiver-owned enforcement: configured receiving gateways consult the shared authoritative registry and recheck it at dispatch admission, failing closed if the registry cannot be read. The portable grant carries its autonomous threshold, not the workspace’s hard maximum, resource bounds or a remote revocation feed. Those additional constraints depend on the receiving guard and exact matching persisted credentials; an unguarded receiver does not gain them automatically. This is not a distributed revocation service.
Future actions, not rollback: revocation or suspension cannot undo a completed action, cancel work already admitted, or revoke credentials at an unrelated gateway. Reactivation does not revive earlier grants: future work requires fresh enrollment and new authority.
Evidence provenance: current directory and identity status are not retroactive proof of the identity used in a historical transaction. Workspace administration records are local records, not signed transaction receipts. The report distinguishes recorded statements from current context; signature verification does not prove business correctness, payment, or a change in SAP.
Before customer use: qualify the intended live identity tenant and workload, install and test the receiving guard at the actual side-effect boundary, and establish deployment-grade authentication, transport, key custody, registry availability and operational controls. Independent acceptance remains required.
Receiving-side decision
Policy has three outcomes. Approval is not execution.
ALLOW
The exact request is within delegated authority and the receiver’s local policy. The receiver-controlled connector may proceed.
REQUIRE APPROVAL
The request is admissible but requires a separately authorized human decision. No protected-system write occurs.
DENY
The request is outside authority, fails verification, or violates the receiver’s policy. No execution occurs.
Final authority stays local
An issuer cannot authorize itself into another organization’s system.
Admissible actionDelegated authority ∩ agent/key binding ∩ exact transaction context ∩ receiving-side trust ∩ receiving-side policy ∩ required approval
Approval cannot widen delegation or override the receiver’s policy. When approval is required, a signed approval changes lifecycle state only; a separately authorized Resume releases execution.
Execution sequence
Signed request → Verify and decide → Approve → Resume → Execute and record
01Signed request
Bind the exact action, resource, counterparty, transaction, amount, currency, purpose, and validity window.
02Verify and decide
Check issuer, delegation, signatures, status, expectations, and receiving-side policy.
03Approve
When required, record the authorized decision. Approval makes no protected-system write.
04Resume
A separately authorized operation binds the accepted approval and releases this exact transaction.
05Execute and record
Derive the local connector operation, validate the result, surface uncertainty, and sign the evidence.
Private verifier release candidate
Verify evidence offline, without an Axynd cloud dependency.
The current verifier accepts caller-supplied trust, time, status, and exact expectations and performs its checks without Gateway, SAP, or runtime network access. It reports completed checks, unchecked claims, warnings, and failures separately.
A verified signature establishes that the configured key issued an intact statement. It does not prove that the business claim is true, that the issuer is reputable, or that the receiving organization should allow the action.
Status: Private invited evaluation. One timed blind evaluation by a non-implementing evaluator completed with no author intervention and a correct reading of the trust model; a second evaluation is still required. This is usability and interpretation evidence, not a security audit or customer validation. The verifier is not public, open, generally available, or production certified.
Application: SAP invoice release
One bounded invoice release, validated in a developer-run CAL appliance.
A developer-run SAP S/4HANA 2025 CAL validation released one existing blocked supplier invoice on September 25, 2026 UTC. The signed transaction bound the invoice, fiscal year, gross amount, currency, action, transaction, and request hash. This is separate from the SAP S/4HANA Cloud Public Edition reference adapter’s contract-tested SAP_COM_0057 scope.
Execution safeguards
- REQUIRE_APPROVAL and APPROVED make zero SAP writes.
- Only a separately authorized Resume may preflight and dispatch.
- Post-dispatch ambiguity becomes EXECUTION_UNKNOWN.
- Axynd does not blindly retry an uncertain write.
- Reconciliation is read-only and requires exact matching evidence.
- The adapter does not create invoices or execute payments.
Status: The CAL release returned HTTP 200 with Success=true; its Axynd-signed receipt and audit verified locally. Cloud Public Edition test-tenant validation remains pending, as does production deployment.
A separate synthetic procurement reference traces supplier, requisition, purchase order, goods receipt, invoice, and invoice-release identifiers through a hash-linked evidence chain. Its invoice-release gate verifies signed delegation, request, approval-challenge, and finance-approval-control artifacts. It makes zero SAP HTTP calls and is not an S/4HANA transaction test or an additional SAP write capability.
Recorded live path: the actual GatewayService, TransactionExecutionService and SAP supplier-invoice adapter handled the release. Explicit Terminal confirmation was translated into a signed approval and a separate signed Resume. Fresh fixture GETs and an adapter-preflight GET checked the bounded target; the successful attempt then sent one Release POST. Earlier authorization-rejected attempts were retained separately, not automatically retried.
Owner-reported follow-up: after the successful release, the owner reported no MRBR match across the variance, manual-payment-block and stochastic-block selections. This was owner-reported follow-up, not an independent automated read-back. Historical invoice-header block values alone do not establish the current financial-accounting payment block.
Live-run limits: 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, independent evaluation, production certification, SAP-signed evidence or a full procure-to-pay validation. No payment, clearing or evidence attachment was performed in this release run. Additional live procurement stages would require separately bounded and tested write adapters.
Implemented readiness boundary: the separate opt-in SAP S/4HANA 2025 FPS01 CAL profile supports verified TLS, Basic or bearer authentication, configured OData metadata paths and optional known test objects using GET requests only. Its sanitized zero-write reports record bounded outcomes, response hashes and write_calls: 0, excluding SAP hosts, credentials, authorization values, business identifiers and response bodies. The live release performed fixture and preflight GETs; that does not establish that the canonical readiness runner was executed.
Separate evidence-deposit capability: a deposit receipt requires exact native-record read-back, with matching digest and byte length from one unambiguous record; HTTP acceptance alone is insufficient. It is signed by the configured Axynd service, not by SAP, and claims no trusted timestamp, immutable retention or compliance certification. This separately tested capability was not exercised by the CAL release.
Application: policy-bound inference
Authoritative policy and placement plans at the control plane. Verified enforcement at the edge.
An inference workload binds the model, task, data classification, and execution policy. The policy constrains eligible runtime provider, region, infrastructure class, public API use and fallback behavior against registered runtime attributes. Confidential compute is a requirement checked against a declared runtime property, not verified platform protection. Latency and cost use estimates, not guarantees.
Reported runtime health is filtered through that policy to produce a signed, short-lived placement plan: a ranked primary target and only explicitly permitted fallback targets. The plan is a recommendation, not a capacity reservation or dispatch command.
A customer-hosted edge agent verifies signed policy state, fails closed when it is stale, and requires a separate runtime-bound execution decision. It consumes that decision before its configured adapter invokes the approved inference endpoint. A secondary target needs its own valid decision and must be permitted by the plan; otherwise a new plan is required. The planner does not reserve capacity, schedule GPUs, deploy models or dispatch workloads. Recovery is explicit, not autonomous failover.
The decision, edge-signed runtime claim, receipt and provenance can be verified offline against reviewer-supplied trust. Runtime claims are self-reports, not hardware attestation. The evidence does not independently establish physical geography, complete data-path confinement or absence of bypass. Deployment owners must establish network restrictions and credential custody.
Bounded live validation: a controlled recovery experiment passed on September 12, 2026, including offline verification of both successful execution bundles. It used a preloaded small model and a synthetic one-token invocation across two Kind clusters on one host, not independently verified physical locations. Representative performance, customer acceptance and production tenant isolation remain unvalidated.
Illustrative control-plane scenario and limits
Not a customer deployment. A separate placement-plan reference path explores one document-analysis feature under two execution policies.
Policy A · Private only: if the approved private runtime is unavailable, stop. Public-provider fallback remains forbidden.
Policy B · Approved secondary: a secondary runtime needs its own valid execution decision and must be permitted by the signed plan. Otherwise, obtain a new plan before recovery. This is controlled recovery, not automatic failover.
The illustration does not demonstrate production tenant isolation or prevent direct access outside Axynd. Identity provisioning, isolation and credential custody remain deployment work.
Customer-bound SaaS execution preview
Bind the application to its customer’s execution policy.
An opt-in application entry point maps an authenticated organization and application identity to deployment-owned customer, agent, policy and model restrictions. Requests cannot override that mapping. Scoped access separates policy preview, authorization and completion; each customer has separate signing keys and policy, decision and provenance stores.
Completion checks application ownership, the exact invocation and the active policy revision, then consumes the decision before the configured adapter runs. Bounded tests reject cross-customer decision reuse and replay, including after restart. This is application-level partitioning, not process, host or network isolation.
Policy preview is simulation only: it does not activate policy, invoke a runtime or authorize fallback. This SaaS entry point does not issue signed placement plans or automate recovery. Integration with the placement-plan and edge flow above remains separate work.
A customer-aware offline report checks the signed execution record and expected application binding against reviewer-supplied trust and context. Runtime claims are gateway-signed configuration self-reports, not hardware attestation or proof of physical location. Source delegation hashes are bound, but the report does not independently reverify the source grants.
Separate SaaS validation: the two-customer synthetic demo uses in-process HTTP and fake provider transports, with both execution bundles reviewed offline. It makes no real inference calls and is not the live recovery experiment above. The separate Auth0-backed Gemma pilot adds real dev-application authentication and bounded container-network checks. Partner-specific identity provisioning, production credential custody, live key rotation and operational controls remain pilot work. Production tenant isolation and customer acceptance remain unvalidated.
Local SaaS runtime validation: a separate developer-run acceptance passed on September 13, 2026 UTC (September 12 locally), using real loopback HTTP and a preloaded qwen2.5:0.5b model through Ollama. Two synthetic customers each completed a one-token invocation. Cross-customer identity and decision use, altered invocations and replay were rejected. Both saved execution bundles passed customer-aware offline verification in separate processes.
Local-run limits: the injected HTTP 503 came from a run-owned relay, not a model or cluster outage; its consumed decision could not be reused. The secondary tripwire received zero calls and was not a second model environment. The harness generated identities, signing keys and review inputs, so separate-process verification is not an independent evaluation. This run used synthetic prompts and does not establish physical location, network confinement, representative performance or production tenant isolation. It is not a customer deployment or automatic recovery.
Auth0-backed Gemma validation
External identity. Policy-bound local execution.
An initial developer-run boundary pilot passed on September 13, 2026. A follow-on single-host 24-hour qualification completed on September 17, 2026 after 86,401 measured seconds. One Auth0 dev application was mapped to a synthetic customer; 48 synthetic one-token gemma3:1b workload rounds completed through Ollama under Axynd delegation and execution-policy checks. The other customer remained a denied target, not a second enrolled Auth0 application.
Passed in this dev pilot
- Real Auth0 access-token authentication followed by Axynd delegation and execution-policy checks.
- All 48 workloads, 48 preflights, 48 resource samples and 48 offline evidence verifications passed.
- Both controlled expiry, restart and recovery exercises passed. Services stopped cleanly with zero gateway exception markers recorded.
- PID 1 open file descriptors held at 7 across all samples; resident memory stabilized at 67.0-67.1 MiB for the final ten samples.
- The run completed 383 logical public-key refreshes from 383 attempts with zero transient failures. Three host activation-leeway acceptances had a maximum delta of 78 milliseconds.
- Earlier boundary tests rejected missing identity, cross-customer access, model changes and replay, including replay after restart.
- The earlier boundary pilot separately ran bounded container-network checks that blocked direct client-to-model access and sampled gateway/model TCP and UDP paths to a known-live local canary before and after restart. Positive controls passed.
Limits of this result
- One dev application, one synthetic enrolled customer and one Docker host, not customer acceptance or an independent audit.
- One-token work every 30 minutes, not continuous inference, representative load or a production SLO.
- Zero transient refresh failures means the bounded retry path was not exercised during this qualification.
- Controlled host-refresh failures, not a live Auth0 outage, live signing-key rotation or immediate client-secret revocation.
- Periodic topology checks, not continuous network or hardware attestation, complete data-path confinement or production tenant isolation. The 24-hour supervisor did not rerun the earlier active bypass and egress probes.
- Offline verification used operator-generated reviewer trust, not an independent audit.
- Host administrators and compromised gateway/backend peers remain outside the tested boundary.
- No proof of physical geography, representative model quality, high availability or managed-service operation.
Auth0 trust path: the host obtains application tokens and automatically refreshes Auth0 discovery and public-key material between workloads on a target 240-second cadence, subject to bounded request and local-operation delays, and once before each round. The gateway verifies RS256 tokens locally against the published ten-minute key snapshot, without Auth0 network access. The Client Secret is not mounted into containers. A logical refresh may make at most three public fetch attempts only for bounded transport failures; cached trust is not extended beyond its original expiry. No transient refresh failure occurred in this qualification, so that retry path did not engage. Auth0 authenticates the application, while Axynd independently checks its delegated authority and execution policy.
Planned architecture
Coordinate globally. Decide locally.
The customer-hosted reference control plane distributes organization-authorized policy and status material and supports edge fleet operations. A future managed Axynd control plane could offer that coordination across customer deployments; it would not create or widen customer authority, approve actions, or proxy every sensitive transaction.
Private keys and ERP credentials stay customer-local. The reference implementation includes OIDC/JWT operator authentication, mTLS-ready edge transport, and an external signing-provider boundary for customer-managed KMS/HSM integrations. A separate Auth0 M2M execution pilot validates a dev-application identity path. Production provider adapters, broader IdP integration, certificate federation, high availability, and managed-service operation remain future deployment work.
Invoice-exception reference path
Bind agreed terms to one exact business action.
The prototype binds a proposer’s signed statement of a versioned invoice exception—parties, allocations and supporting-record hashes—to one exact action. Each revision requires originator finance authorization; the receiving gateway applies its own policy, and a separately authorized Resume releases execution.
Revised terms require a new signed revision. Axynd does not negotiate, establish counterparty assent, or prove damage or liability. Its evidence authenticates the statement and recorded action, not the commercial truth behind them.
Bounded design-partner validation
Bring one agent action you won’t allow today.
Identify the action, the system of record and its owner. Bring an engineering owner, a security reviewer and a non-production environment to define the exact authority, the approval and execution path, and the evidence for a bounded pilot.