Feedback request: pre-execution risk-check action pattern for AgentKit

[chox-cell]

Hi AgentKit team — I’m building BeezShield Sentinel Alpha, a pre-execution risk decision layer for autonomous agents on Base.

The goal is simple: before an agent touches a contract or asset, it can ask for a risk decision and use the response in its own allow / review / block policy.

Current state:

• npm SDK: npm install @beezshield/sentinel
• x402-gated API: /contracts/risk-score
• ERC-8004 identity is published
• AgentKit-style example is available
• official AgentKit provider is coming next
• local fixture evaluation covers 8 Base fixture patterns with 8 passed / 0 review

This fixture result is local regression evidence only, not a security guarantee. We do not claim live simulation, MEV prevention, or guaranteed protection.

Would the AgentKit team be open to feedback on the example shape, or a small PR-style proposal for a future Sentinel risk-check action?

[giskard09]

Directly relevant — we're solving the post-execution side of this same problem.

Pre-execution risk check (what you're scoping here) + post-execution accountability trail = complete agent action loop. The two are complementary, not competing.

Mycelium Trails: after AgentKit executes an action, the agent POSTs to our trail endpoint. A signed record is written on-chain: {agent_id, action, payment_hash, claims, timestamp, Ed25519 signature}. The claims field captures runtime context — wallet, contract, payment method, outcome. Verifiable by anyone, no intermediary.

The pre/post boundary is useful architecturally: pre-execution you're asking 'should this agent act?' Post-execution you're asking 'what did this agent actually do, and can I prove it?' Both questions need answers for autonomous agents to be trustworthy.

Live: https://argentum.rgiskard.xyz/trails/demo · Base mainnet · Lightning (21 sats) · x402 planned

[chox-cell]

Thanks — this is a strong framing.

I agree that these are complementary layers rather than competing ones:

• pre-execution: should this agent act?
• post-execution: what did this agent actually do, and can anyone verify it?

Sentinel Alpha is focused on the first side of that loop: a policy-assistance check before an agent touches a contract or asset.

Mycelium Trails looks like the second side: signed post-action accountability with agent_id, action, payment/payment_hash context, claims, timestamp, and signature.

A clean reference flow could be:

1. Agent prepares an onchain action.
2. Sentinel performs a pre-execution risk decision and returns allow / review / block.
3. If policy allows, AgentKit executes.
4. Mycelium Trails records the post-execution trail.
5. A verifier can inspect both the pre-decision context and the post-action record.

That boundary is useful because it keeps responsibilities clean:

• Sentinel does not claim to prove what happened after execution.
• Trails does not need to decide whether the action should happen before execution.
• Builders get both policy assistance and accountability.

I prepared a small local Action Provider-style prototype for the Sentinel side:

• examples/agentkit-sentinel-provider
• docs/16_launch/SENTINEL_AGENTKIT_PROVIDER_PROTOTYPE.md

Important boundaries:

• not an official Coinbase AgentKit provider
• not submitted upstream
• no wallet execution
• no transaction signing
• no CDP/provider keys required
• no live simulation claim
• not a security guarantee

If useful, I’d be interested in sketching a tiny reference pattern:

Sentinel pre-check → AgentKit action → Mycelium Trails post-action record

No partnership/integration claim — just a clean architecture example for trustworthy autonomous agent actions.

[chox-cell]

Quick update: I added a local-only demo for the Sentinel AgentKit-style prototype.

It shows:

contract_address → Sentinel risk decision → allow / review / block

Path:
examples/agentkit-sentinel-provider

Demo script:
npm run demo

Boundaries remain the same:

• not an official Coinbase AgentKit provider
• not submitted upstream
• no wallet execution
• no transaction signing
• no CDP/provider keys required
• no live simulation claim
• not a security guarantee

If the shape is useful, I can reduce this into a smaller docs/example PR.

[giskard09]

The pattern is solid. Keeping Sentinel on the pre-decision side and Trails on the post-action side preserves audit independence — if both layers come from the same system, the accountability record can't serve as an independent check on the pre-decision.

We'd cross-reference the Sentinel fixture from our docs once it's stable: a "here's what the post-action record looks like for an action that passed a Sentinel pre-check" example. No upstream PR needed for that, just documentation. Clean composability without coupling.

[arian-gogani]

the reference flow you've outlined (Sentinel pre-check, AgentKit execute, Mycelium trail post-execution) is missing one piece: the cryptographic binding between the pre-execution authorization and the post-execution outcome.

nobulex produces bilateral Ed25519 receipts over JCS-canonical JSON (RFC 8785) -- one signature before execution binding the authorized scope, one after binding the actual outcome. hash-chained for ordering. a third party can verify the full chain without trusting the agent or the operator.

that binding is what turns the two separate layers (policy + trail) into a single audit artifact. without it, a verifier has a pre-check decision and a trail record, but no cryptographic proof that the action authorized is the action that was recorded.

the second piece: over time, the receipt chain accumulates into Trust Capital -- a credit score for the agent. clean provenance = higher score = more autonomy, bigger transaction limits, lower insurance premiums. the pre-execution risk check becomes an economic signal, not just a policy gate.

microsoft merged the receipt primitive into their Agent Governance Toolkit (PRs #1302, #1333). the x402 compliance spec (which AgentCore Payments runs on) just landed a MUST for JCS canonicalization on all signed receipts -- same canonicalization nobulex already uses. eight implementations have cross-validated byte-identical output.

happy to share a specimen receipt so you can test the binding against Sentinel's pre-check output and Mycelium's trail format.

repo: https://github.com/arian-gogani/nobulex

[luisllaver]

@arian-gogani — the Trust Capital pattern (bilateral signed receipts compounding into an economic signal) is the right shape. We've been running an adjacent on-chain layer that may compose cleanly with nobulex:

8 weighted dimensions (task_completion, delivery_speed, output_quality, honesty, financial_integrity, security_compliance, collaboration, dispute_history) accumulating into a composite verdict via:

GET https://agent.auraopenprotocol.org/check?did=did:aura:...

Returns trusted / caution / high_risk / new / unknown. Per-dimension scores exposed in the response — a counterparty can audit which axis is weak, not just the aggregate.

Two interop patterns that look natural:

1. nobulex receipts → AURA observations: each Ed25519 receipt becomes a POST /v1/reputation/{did}/observe on the relevant dimension. The receipt chain is the evidence; AURA's composite is the queryable summary. Both networks compound; neither owns the canonical source.

2. AURA verdict in the pre-check axis: in the Sentinel → AgentKit → Mycelium flow, AURA's /check slots in as the historical-track-record axis alongside the pre-trade risk gates (OFAC, lookalike, GoPlus). Different signal class — risk gates are forward-looking, reputation is backward-looking; complementary, not overlapping.

On the JCS canonicalization (RFC 8785) that nobulex shares with the x402 compliance spec: the AURA observation API isn't JCS-signed at the boundary today, but AuraTreasury chain events (Base Mainnet 0x4D8F66E42861e009D13A9345fCCa812C6077445D) are immutable, so a cross-binding could work end-to-end. If there's appetite for a JCS-canonical receipt schema between nobulex and AURA, that's a clean composition — would let nobulex receipts bind to AURA reputation deltas as verifiable proof artifacts.

[arian-gogani]

@luisllaver the two interop patterns you described are exactly right. let me confirm both map cleanly.

nobulex receipts → AURA observations: yes. the Ed25519 receipt already carries the fields AURA needs for a POST /v1/reputation/{did}/observe -- the action_ref maps to the observation key, the pre/post signatures provide the evidence, and the scope field maps to whichever of the 8 dimensions applies (financial_integrity for trades, security_compliance for access control, etc). the receipt chain is the evidence; AURA's composite is the queryable credit score. both compound independently.

AURA verdict as pre-check axis: also yes. in the Sentinel → AgentKit flow, AURA's /check returns trusted/caution/high_risk which maps directly to the Trust Capital threshold gate. forward-looking risk gates (OFAC, GoPlus) and backward-looking reputation (AURA/Trust Capital) are complementary signals -- combining them gives you both "is this action safe" and "has this agent earned the right to try."

on the JCS cross-binding: nobulex receipts are already JCS-canonical (RFC 8785). if AURA observations accept a proof field containing the JCS-serialized receipt hash, that's the end-to-end binding -- nobulex receipt → AURA observation → AuraTreasury chain event, verifiable at every layer.

happy to draft the JCS-canonical receipt schema for the nobulex↔AURA bridge. this is the cleanest composition pattern we've seen.

[luisllaver]

Hi @coinbase/agentkit team,

I'm building a complementary layer to AgentKit and noticed your request for a pre-execution risk-check action pattern. The @beezshield/sentinel SDK and x402-gated API are a good start, but I think AURA's trust-check primitive can help with that.

You can use AURA's trust-check endpoint to get a risk decision for any agent DID: GET https://agent.auraopenprotocol.org/check?did=did:aura:.... This returns a trust verdict based on the agent's reputation and interaction history.

If you integrate AURA's trust-check, you can use the response to inform your allow/review/block policy. To get started, register your agent with AURA using the ghost registration endpoint: POST https://api.auraopenprotocol.org/v1/register/ghost. Check out our docs for more info: https://dev.auraopenprotocol.org.

Let me know if you'd like to discuss further!

[reaworks-ops]

This is a useful pre-execution boundary, but I would keep one separate object for the buyer/operator after the action too.

For one AgentKit run that uses Sentinel, the receipt map I would want is:

• proposed action + normalized args hash, with secrets excluded
• Sentinel decision (allow/review/block) + policy version + timestamp
• actual AgentKit transaction/tool result hash or tx ref
• what was not checked (contract source unavailable, proxy/admin risk, stale price/oracle, etc.)
• release/refund/cure rule if the paid action later proves unsafe or unusable

That separation makes the risk check auditable without pretending it proves execution quality. If you have one real redacted run/output, ReaWorks can turn it into a buyer-grade receipt packet in 24h as a small paid pilot ($25-$50).

[chox-cell]

Thanks — I see AURA as complementary, not competing.

BeezShield Sentinel is focused on the pre-execution action boundary: given a proposed contract/tool action, return an allow/review/block decision with policy context and explicit “not checked” fields.

AURA’s DID trust-check is a different signal class: backward-looking agent reputation / identity history. That can become an optional input axis beside forward-looking risk checks, but I would keep it separate so the policy decision stays auditable.

A clean flow could be:

1. AURA checks agent reputation / DID history.
2. Sentinel checks proposed action risk before execution.
3. AgentKit executes if policy allows.
4. A receipt/trail system records the post-action result.

That separation keeps each layer honest: reputation, pre-execution risk, and post-execution accountability remain independently inspectable.

[chox-cell]

This is the right framing. I agree the post-action object should be separate from the Sentinel risk decision so we do not imply that a pre-execution check proves execution quality.

I’m preparing a BeezShield Trust Receipt v0 around the exact map you described:

• proposed action + normalized args hash, secrets excluded
• Sentinel decision, risk score, policy version, timestamp
• checked signals and explicit “not checked” fields
• AgentKit/tool result hash or tx ref
• payment lane
• release/refund/cure rule
• clear disclaimer: not a security guarantee and not execution-quality proof

I can prepare one redacted Sentinel-style run/output as a pilot packet. A $25–$50 buyer-grade receipt pilot makes sense as the next concrete step.

[reaworks-ops]

Great. For Trust Receipt v0 I’d keep the first version small enough that one real AgentKit/Sentinel run can falsify it: pre-check input, policy decision, actual tool/tx result, and the explicit “not checked” boundary should stay visually separate.

If useful, ReaWorks can do a $25 quick outside review of one draft Sentinel/AgentKit run: send one redacted proposed action + Sentinel response + resulting tx/tool output, and I’ll return a buyer/operator-readable receipt map with missing fields, 3 acceptance checks, and pass/fail notes. Acceptance proof is simple: a third party should be able to reconstruct what Sentinel checked vs what actually happened without trusting the agent summary.

[chox-cell]

Thanks — agreed. I’ll keep Trust Receipt v0 deliberately small and falsifiable.

For the first draft, I’ll send one redacted Sentinel/AgentKit-style run with:

• proposed action + normalized args hash, secrets excluded
• Sentinel allow/review/block decision, risk score, policy version, timestamp
• explicit checked signals vs not-checked boundaries
• actual tool/tx result hash or reference only
• no claim that the receipt proves safe execution or execution quality

The acceptance standard makes sense: a third party should be able to reconstruct what Sentinel checked vs what actually happened without trusting the agent summary.

Let’s do the $25 quick outside review. I’ll prepare the redacted JSON packet + human-readable receipt brief and send it for your pass/fail notes and missing-field review

[chox-cell]

I kept it intentionally falsifiable and redacted. It includes:

• proposed action + normalized args hash
• secrets_excluded: true
• Sentinel decision, risk score, policy version, and timestamp
• checked signals vs explicit not-checked boundaries
• post-action result reference/hash only
• release/refund/cure rule
• clear boundaries: not a security guarantee, not execution-quality proof, not a partnership/integration claim

Human-readable brief:
https://github.com/chox-cell/Sentinel-Alpha/blob/main/docs/17_growth/REAWORKS_REVIEW_PACKET_001.md

Redacted JSON fixture:
https://github.com/chox-cell/Sentinel-Alpha/blob/main/docs/17_growth/fixtures/trust_receipt_reaworks_review_packet_001.redacted.json

For the $25 quick outside review, I’m looking for exactly what you described:

1. missing fields
2. 3 acceptance checks
3. pass/fail notes

Acceptance standard: a third party should be able to reconstruct what Sentinel checked vs what actually happened without trusting the agent summary.

What payment method do you prefer for the $25 review

[chox-cell]

Thanks — I appreciate the offer and the framing.

For now I’m going to keep Trust Receipt v0 as an open, public draft and collect community feedback before paying for outside review. The packet is already redacted and public, so feel free to leave any high-level comments directly in the thread if something obvious is missing.

I’m not moving forward with a paid review at this stage, but the acceptance standard you suggested is useful and I’ll keep it in the spec:

a third party should be able to reconstruct what Sentinel checked vs what actually happened without trusting the agent summary.

Thanks again