Precision Decisioning & Agentic Trust: Cryptographic proof of authorization for agent workflows

Problem: Agent workflows need deterministic authorization, not probabilistic guardrails

When agents orchestrate multi-step workflows — tool calls, sub-agent delegation, external API access — the authorization model today is probabilistic: system prompts, content filters, retry-and-hope. There is no verifiable proof that a specific action was authorized by a specific policy for a specific intent.

This matters for Agent Framework because:

Graph-based workflows route decisions through multiple nodes. Each edge crossing is an authorization boundary with no verifiable proof of transit.
Multi-agent orchestration delegates between agents. The receiving agent has no way to verify the delegating agent's authority.
Tool execution is gated by capability declarations, but there's no signed proof that a tool invocation was authorized against a specific policy at a specific time.

Three Primitives for Verifiable Agent Authorization

We've built and deployed a governance layer that addresses this with three primitives:

1. Precision Decisioning (ALLOW / CLAMP / DENY)

Every agent action request gets a deterministic, signed decision — not a score, not a probability:

ALLOW: Action authorized within policy bounds
CLAMP: Action partially authorized, constrained to safe envelope
DENY: Action rejected, with signed proof of denial

2. Signed Evidence Trail

Every decision is logged to an append-only, signed evidence ledger. Each record links to the previous for tamper detection. Evidence is signed with post-quantum cryptography (ML-DSA-87 / FIPS 204).

3. Verifiable Identity (Intent-to-Action Binding)

Each request binds the agent's stated intent to the authorized action. The verification proof can be validated independently — no callback needed.

Live Example

The gateway is live at governance.taskhawktech.com and implements the A2A protocol.

# Free signup — 100 calls/month, no credit card
curl -s -X POST https://governance.taskhawktech.com/signup \
  -H "Content-Type: application/json" \
  -d '{"agent_id": "agent-framework-test"}'

# Verify an action
curl -s -X POST https://governance.taskhawktech.com/governance/verify \
  -H "X-API-Key: YOUR_KEY_FROM_SIGNUP" \
  -H "Content-Type: application/json" \
  -d '{
    "action_type": "tool_call",
    "action_payload": {"tool": "execute_sql", "query": "SELECT * FROM users"},
    "agent_id": "agent-framework-test"
  }'

Each response includes a signed verification proof, sequential evidence linkage, and a deterministic decision. Downstream services can validate the proof independently.

x402: Payment as Identity (No API Key Path)

For agents operating without pre-provisioned credentials, the gateway supports the x402 payment protocol — USDC on Base. The agent's wallet address becomes its identity. No signup, no API key, no OAuth.

Integration Surface with Agent Framework

This could integrate as:

Workflow middleware: Gate edge transitions with signed decisions
Tool authorization wrapper: Tool fires only if governance returns ALLOW or CLAMP
Agent delegation verification: Delegation carries a signed proof that the receiving agent verifies independently
Evidence integration with checkpointing: Sequential evidence records map to Agent Framework's checkpoint model — you can verify authorization state at any point in a workflow's history

Resources

Gateway: https://governance.taskhawktech.com
A2A Agent Card: https://governance.taskhawktech.com/.well-known/agent.json
SDK: pip install kevros-agent-framework
Docs: https://governance.taskhawktech.com/docs

Live Evidence — Real API Response (Feb 24, 2026)

To back up the proposal with verifiable data: here is a real response from the live gateway at governance.taskhawktech.com.

Real Governance Decision

curl -s -X POST https://governance.taskhawktech.com/governance/verify \
  -H "X-API-Key: kvrs_..." \
  -H "Content-Type: application/json" \
  -d '{
    "action_type": "deploy_production",
    "action_payload": {"service": "api-v2", "env": "production", "version": "3.1.0"},
    "agent_id": "evidence-test-agent"
  }'

Response (real):

{
  "decision": "ALLOW",
  "verification_id": "98987614-5b29-4b00-b48e-d933b191c3f1",
  "applied_action": {"service": "api-v2", "env": "production", "version": "3.1.0"},
  "policy_applied": {},
  "reason": "Action within policy bounds",
  "timestamp_utc": "2026-02-24T02:12:43.817151+00:00"
}

How this maps to Agent Framework

Deterministic decision — Each transition between agents or tool calls is gated by a signed decision (ALLOW/CLAMP/DENY), not a prompt-based check.
Signed verification proof — When Agent A delegates to Agent B in Agent Framework's orchestration graph, the proof travels with the delegation. Agent B validates it locally — no callback needed.
Sequential evidence records — Each decision links to the prior record for tamper detection. This maps directly to Agent Framework's checkpointing: you can verify authorization state at any point in a workflow's history.
Tamper-evident evidence — Modify any prior record and the chain breaks detectably. For Agent Framework's time-travel debugging, this means you can prove the authorization state was valid at any historical point.

x402: Autonomous Agent Payment (No Pre-Provisioned Keys)

For Agent Framework's multi-agent scenarios where agents operate without human-provisioned credentials, the gateway supports x402 (HTTP 402 payment protocol). The agent's wallet address becomes its identity. Payment authorizes the endpoint call. No signup, no API key, no OAuth flow.

Try it yourself

# Free signup — 100 calls/month, no credit card
curl -s -X POST https://governance.taskhawktech.com/signup \
  -H "Content-Type: application/json" \
  -d '{"agent_id": "agent-framework-test"}'

Agent Card (A2A): https://governance.taskhawktech.com/.well-known/agent.json
Docs: https://governance.taskhawktech.com/docs

Happy to collaborate on a reference middleware implementation for Agent Framework if there's interest.

knuckles-stack

knuckles-stack We provide Agent Middleware to enable the types of integration mentioned in this issue. Have you looked at these capabilities?

Mark Wallace (@markwallace-microsoft)

Mark Wallace (@markwallace-microsoft) Yes. We built a governance middleware integration against agent-framework 1.0.0rc1.

Two middleware classes:

KevrosGovernanceMiddleware (extends AgentMiddleware) - gates every agent run with a signed authorization decision
KevrosFunctionMiddleware (extends FunctionMiddleware) - binds intent to each tool call with cryptographic proof

Dual-mode provider: remote gateway (SaaS) and embedded local enforcement for air-gapped workloads.

Same GovernanceProvider protocol, middleware doesn't know which backend it's using.

Agent Card: https://governance.taskhawktech.com/.well-known/agent.json

Happy to share the middleware source or provide repo access. mailto:[email protected]

Mark Wallace (@markwallace-microsoft)

Mark Wallace (@markwallace-microsoft) Published to PyPI: kevros-agent-framework (0.1.1). Same middleware described above, installable via pip install kevros-agent-framework. Would welcome your feedback on the integration surface when time allows.

Thanks,
-JM

On the multi-agent delegation authorization problem — one piece that could feed into the ALLOW/CLAMP/DENY decisioning is on-chain credential verification.

When Agent A delegates to Agent B, the policy engine can check what Agent B's wallet holds as an authorization input:

import requests

resp = requests.post("https://api.insumermodel.com/v1/trust",
    headers={"X-API-Key": api_key, "Content-Type": "application/json"},
    json={"wallet": delegate_agent_wallet}
)
trust = resp.json()["data"]["trust"]

# 17 checks across 4 dimensions: stablecoins, governance, NFTs, staking
dimensions_active = trust["summary"]["dimensionsWithActivity"]
total_passed = trust["summary"]["totalPassed"]

# Feed into policy decision
if dimensions_active == 0:
    decision = "DENY"   # No on-chain presence
elif total_passed < 3:
    decision = "CLAMP"  # Limited credentials — constrain scope
else:
    decision = "ALLOW"  # Established on-chain presence

Key properties that fit your authorization model:

ECDSA P-256 signed — every response is cryptographically signed, verifiable via JWKS at /.well-known/jwks.json. This gives you the "signed proof that an action was authorized at a specific time" you describe.
Deterministic — same wallet, same block = same result. No probabilistic scoring.
Privacy-preserving — returns booleans only, never raw balances.
31 chains — one call covers the EVM ecosystem + Solana.

The signed attestation could slot into your hash-chained provenance log as a verifiable authorization artifact.

AI Agent Verification API guide · Docs · OpenAPI spec

Douglas Borthwick (@douglasborthwick-crypto)

Douglas Borthwick (@douglasborthwick-crypto) Interesting. On-chain credential verification as a policy input for delegation is a valid pattern. The gateway already supports wallet-as-identity via x402. Without an API key, agents authenticate by signing a USDC micropayment on

Base:

curl -X POST https://governance.taskhawktech.com/governance/verify \
  -H "Content-Type: application/json" \
  -d '{"action_type": "TRANSFER", "action_payload": {"amount": 100}, "agent_id": "demo-agent"}'

Returns 402 Payment Required with an x402 payment header. The agent's wallet signs the payment to complete the call. The signed transaction is the credential. The governance response includes a signed verification proof and tamper-evident evidence record.

Where this gets interesting for Agent Framework middleware (cc Mark Wallace (@markwallace-microsoft) ): in multi-agent delegation, the delegating agent's wallet reputation could feed into the policy engine as an additional authorization signal alongside the signed decision. The GovernanceProvider protocol we built against 1.0.0rc1 already supports extensible policy inputs. On-chain presence checks would be a natural addition to the authorization context.

Open to exploring how wallet credential verification layers into governance decisioning for delegation scenarios.

-JM

Good to see this moving forward — the GovernanceProvider extensible policy inputs are the right integration surface.

Since my last comment, the trust profile covers 4 dimensions for EVM wallets (stablecoins, governance, NFTs, staking — 17 checks across 32 chains). Pass a solanaWallet or xrplWallet and it extends to 6 dimensions / 20 checks. Same ECDSA-signed output, same JWKS.

For the delegation scenario you described: the signed trust attestation could be a first-class policy input alongside your evidence records. The middleware calls /v1/trust once at delegation time, and the signed result becomes part of the authorization context that travels with the delegation chain.

Happy to test against governance.taskhawktech.com if you want to try the round-trip:

curl -s -X POST https://api.insumermodel.com/v1/keys/create \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","appName":"TaskHawk Governance","tier":"free"}'

Docs

Mark Wallace (@markwallace-microsoft)

The three-primitive model (Precision Decisioning, Signed Evidence Trail, Verifiable Identity) is well-structured. On the identity primitive specifically, there's a layer beneath the intent-to-action binding that could strengthen the authorization chain: runtime-level identity verification.

The governance gateway answers "is this action authorized by policy?" But before that question, there's a prior question: "is the agent making this request operated by a known, legitimate runtime?" A compromised runtime could issue agents that pass policy checks but shouldn't exist in the first place.

The Open Agent Trust Registry (OATR) handles this. Agent runtimes register Ed25519 public keys with automated domain verification and cryptographic proof-of-key-ownership. The registry manifest is Ed25519-signed and verifiable locally (no external API calls in the request path).

How this composes with the governance gateway:

Agent requests tool execution
  -> Step 1: OATR attestation check — is this agent from a registered runtime? (local, <1ms)
  -> Step 2: Governance gateway — is this action ALLOW/CLAMP/DENY per policy? (sync or async)
  -> Step 3: Execute tool
  -> Step 4: Signed evidence record — links runtime identity + policy decision + action result

The OATR attestation in Step 1 gives the evidence record in Step 4 a cryptographic anchor: the same Ed25519 key that proved the runtime's identity gets referenced in the evidence chain. This binds the "who" (runtime identity) to the "what" (authorized action) to the "proof" (signed evidence).

For the multi-agent delegation scenario: when Agent A delegates to Agent B, Agent B's OATR attestation proves it comes from a registered runtime. The governance gateway then checks whether that runtime is authorized to receive delegations. Two independent verification layers, both cryptographic, composable via the AgentMiddleware interface Mark Wallace (@markwallace-microsoft) mentioned.

The Agent Identity Working Group has been building and testing exactly this pattern. Three ratified specs (QSP-1 envelope, DID Resolution, Entity Verification), conformance tests across 6 independent projects, and a production deployment with verified agent handoffs across 12 countries. The execution attestation layer (ArkForge) produces signed receipts with agent_identity and delegation_path fields, which is structurally similar to your evidence records.

MIT licensed, 7 registered issuers, automated CI-verified registration. npm SDK: @open-agent-trust/registry.

This is exactly the gap that Pathcourse Health's identity and trust infrastructure is designed to close. PCH's ERC-8004 standard and Path Score system provide cryptographic agent identity and deterministic authorization proofs — each agent in a workflow carries a verifiable cert tier and a Path Score that encodes its trust boundaries, delegated permissions, and policy attestations on-chain. Rather than relying on system prompts as probabilistic guardrails, orchestrators can verify at each delegation hop whether a sub-agent is cryptographically authorized to perform a specific action for a specific intent, making authorization auditable and deterministic rather than emergent. If you're building graph-based agent workflows in microsoft/agent-framework, PCH's cert_registry and ERC-8004 identity layer can serve as the verifiable trust anchor at every node in your execution graph — happy to walk through the integration pattern.

Working code example: https://github.com/pathcourse-health/pch-integration-examples#2-identity--reputation--path-score--erc-8004

On the Signed Evidence Trail primitive specifically: there is a trust boundary worth separating — evidence signed by the same gateway that enforced the decision is only verifiable against that gateway. If the operator runs the gateway, the evidence is only as trustworthy as the operator.

A complementary primitive is external anchoring of the evidence itself: aotrust-protocol (pip install aotrust-protocol) takes a canonical action/decision record, signs it with Ed25519, and anchors a Provenance Data Record (PDR) on NEAR. The receiving agent in a delegation — or any downstream auditor — verifies proof-of-existence offline or at https://verify.aotrust.link, without querying or trusting the enforcement layer. For the multi-agent delegation case: the delegating agent notarizes the authorization grant, the receiving agent verifies the signature before accepting the delegation — transit proof across the edge crossing, no wallet-coupled identity required. Middleware stays the enforcement point; the PDR is the tamper-evident evidence that the decision existed. Free tier: 5 PDRs/day, works alongside existing AgentMiddleware integrations.

This maps closely to the runtime control problem we're exploring in Aegisora: the host should be able to establish policy, authorization and approval before the consequential tool execution occurs.

The important part is proving that the decision applies to the exact tool invocation that eventually executes.

Independent testing is welcome:
aegisora-ai/aegisora#28

AEGISORA-W31-MAF

The intent-to-action binding is an interesting direction. For multi-step agents, proving that a specific tool call was authorized under a specific policy could become as important as the authorization decision itself.

How do you see this working across delegated sub-agents without making the execution path too heavyweight?

Thanks for the write-up. The framing — "Every agent action request gets a deterministic, signed decision — not a score, not a probability" — is the right target. Two things in the ledger design that look under-specified, from work on reproducible evidence grading for agentic trust.

1. The decision enum needs a fourth, non-failure state for unconfirmable authorization.

ALLOW / CLAMP / DENY covers the cases where the policy engine can actually reach a conclusion. Across a graph of N edges, though, some will be unverifiable at audit time: the authoritative scope registry was unreachable when the decision was made, a delegation hop's issuer-scope record wasn't captured, or the prior ledger link exists but its underlying evidence expired. Signing that record doesn't resolve it — it just signs an unconfirmed conclusion.

The trap is folding that state into DENY. That converts "we could not confirm authorization" into "this action was proven unauthorized," which states something unproven. We use a separate four-state authorization result — verified / unresolved / rejected / quarantined — where unresolved is deliberately not counted as a failure when aggregating across edges. The canonical worked contrast is two records carrying the same valid signature:

caseB1: signature valid, issuer-scope registry unavailable at verification time -> authorization = unresolved (hold for manual review; do not rely).
caseB2: signature valid, registry confirms the issuer is out of scope -> authorization = rejected (do not accept).

Same wire bytes, opposite meaning. A ledger that only exposes ALLOW / CLAMP / DENY cannot represent this distinction without being wrong on one side.

2. Signing a record proves integrity; it doesn't make the conclusion independently reproducible.

You write that the proof "can be validated independently — no callback needed." Today that means checking the ML-DSA-87 signature and the hash chain. It doesn't let an auditor recompute the grade from the underlying evidence. If each ledger record also carried the canonical evidence plus a payload_digest (SHA-256 over the domain grades and authorization result), a third party could rerun the grader and confirm the record's conclusion was the deterministic output of that evidence — not merely that it wasn't altered afterward.

We just ran this on the exact edge above (a tool_call whose signature verifies but whose issuer-scope proof is unconfirmable). Save the input below as input_af_edge.json, then:

git clone https://github.com/LGD-Eval/evaluation-protocol && cd evaluation-protocol
python tools/evidence-grader.py --json input_af_edge.json   # --selftest: 15 invariants pass

{
  "subject": "AF delegation edge — tool_call execute_sql; signed decision present but issuer-scope proof unconfirmable at decision time",
  "domains": {
    "D1": [
      { "claim": "Decision record signature cryptographically valid (ML-DSA-87 / FIPS 204 replay on frozen decision vector)",
        "grade": "V", "kind": "repro-test",
        "source": "signature replay at audit time on frozen decision vector T-AF-1",
        "reproducible": true, "timestamped": true },
      { "claim": "Delegating agent authorized to issue this tool_call decision for this intent",
        "grade": "L", "kind": "audit",
        "source": "delegating agent self-declaration; authoritative scope registry unreachable at decision time and not re-confirmable from the ledger alone",
        "reproducible": false, "timestamped": false }
    ]
  },
  "authorization": {
    "result": "unresolved",
    "reason": "authoritative issuer-scope information unavailable at decision time; missing evidence of authorization is not demonstrated invalid authorization",
    "relying_party_action": "do not fold into DENY; hold per risk policy (manual review / deny-open) and re-confirm scope when the registry returns"
  }
}

Result: overall_failure_class = unresolved, authorization.result = unresolved, payload_digest = d1dcfe48b4f712ae. The digest is stable across reruns (the timestamp is excluded from the hash), so the binding between intent, decision, and evidence is itself reproducible. The grader and the two cases above are Apache-2.0 reference code, not a service: tools/evidence-grader.py.

Not opening a PR here — just flagging the unresolved state and the reproducible-record fields as schema questions before the ledger is treated as an audit artifact rather than merely an integrity log.

Disclosure: this comment was prepared with material AI assistance (issue analysis and proposed design wording); I reviewed the content and stand behind the technical claims, per the repo's AI-Assisted Contributions Policy.

Thanks for sharing the scenario and the middleware integration.

We do not plan to adopt this governance integration as a first-party Agent Framework feature. Agent and function middleware provide extension points for application-owned authorization checks. As you described above, you have used those hooks and published an independently maintained package.

The proposed gateway, policy decisions, signed evidence ledger, cryptographic trust model, and optional wallet/payment integration belong in that outside package. No concrete missing framework extension point has been established here that would require MAF to own those contracts.

Closing this request as not planned for this repository. This is a product-ownership decision, not an assessment of the external package's security or compliance claims.

Navigation Menu

Repository navigation

Precision Decisioning & Agentic Trust: Cryptographic proof of authorization for agent workflows #4203

Problem: Agent workflows need deterministic authorization, not probabilistic guardrails

Three Primitives for Verifiable Agent Authorization

1. Precision Decisioning (ALLOW / CLAMP / DENY)

2. Signed Evidence Trail

3. Verifiable Identity (Intent-to-Action Binding)

Live Example

x402: Payment as Identity (No API Key Path)

Integration Surface with Agent Framework

Resources

Live Evidence — Real API Response (Feb 24, 2026)

Real Governance Decision

How this maps to Agent Framework

x402: Autonomous Agent Payment (No Pre-Provisioned Keys)

Try it yourself

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Precision Decisioning & Agentic Trust: Cryptographic proof of authorization for agent workflows #4203

Description

Problem: Agent workflows need deterministic authorization, not probabilistic guardrails

Three Primitives for Verifiable Agent Authorization

1. Precision Decisioning (ALLOW / CLAMP / DENY)

2. Signed Evidence Trail

3. Verifiable Identity (Intent-to-Action Binding)

Live Example

x402: Payment as Identity (No API Key Path)

Integration Surface with Agent Framework

Resources

Activity

jmcgraw434 commented on Feb 24, 2026

Live Evidence — Real API Response (Feb 24, 2026)

Real Governance Decision

How this maps to Agent Framework

x402: Autonomous Agent Payment (No Pre-Provisioned Keys)

Try it yourself

markwallace-microsoft commented on Feb 24, 2026

jmcgraw434 commented on Feb 25, 2026

jmcgraw434 commented on Feb 26, 2026

douglasborthwick-crypto commented on Feb 28, 2026

jmcgraw434 commented on Mar 1, 2026

douglasborthwick-crypto commented on Mar 22, 2026

FransDevelopment commented on Mar 24, 2026

alex-pathcourse commented on Apr 23, 2026

GitSerge-crypto commented on Sep 1, 2026

ozereray commented on Sep 10, 2026

ozereray commented on Sep 16, 2026

zhaoxinghua09-cell commented on Oct 17, 2026

eavanvalkenburg commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions