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

[jmcgraw434]

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:

1. Workflow middleware: Gate edge transitions with signed decisions
2. Tool authorization wrapper: Tool fires only if governance returns ALLOW or CLAMP
3. Agent delegation verification: Delegation carries a signed proof that the receiving agent verifies independently
4. 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

[jmcgraw434]

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

1. Deterministic decision — Each transition between agents or tool calls is gated by a signed decision (ALLOW/CLAMP/DENY), not a prompt-based check.

2. 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.

3. 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.

4. 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.

[markwallace-microsoft]

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

[jmcgraw434]

@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:governance@taskhawktech.com

[jmcgraw434]

@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

[douglasborthwick-crypto]

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

[jmcgraw434]

@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 @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

[douglasborthwick-crypto]

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":"you@taskhawktech.com","appName":"TaskHawk Governance","tier":"free"}'

Docs

[FransDevelopment]

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 @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.

[alex-pathcourse]

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