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.