[RFC] ATSP v1.0 — Proposed Security Standard for elizaOS On-Chain Agents

[LCTXTECH]

Hey elizaOS community 👋
I've been building AgentSentry — a security circuit-breaker middleware for elizaOS agents managing real capital on Solana — and in the process drafted a proposed open standard for agent intent declaration that I'd love community feedback on.
The Problem: elizaOS agents executing on-chain actions (swaps, transfers, LP positions) have no standardized security enforcement layer. A misconfigured agent or LLM hallucination can drain a treasury before any human can intervene.
The Proposal: ATSP v1.0 (Agentic Transaction Security Protocol) — a lightweight standard requiring agents to produce a signed intent declaration (SHA-256 hash, reasoning trace, IPI-cleared flag) before any on-chain action, submitted to a security middleware that validates against configurable policies.
What's Already Built:
• @agentsentry/atsp v1.0.0 on npm — TypeScript types, validation helpers, 23 tests
• Full protocol spec at agentsentry.net/protocol/atsp
• AgentSentry middleware: Squads V4 Proposer integration, circuit-breaker logic, multi-channel alerts
• Works with elizaOS today — wrap any elizaOS action with a single sentryCheck() call
Questions for the community:
• Would elizaOS core consider ATSP as a recommended security layer for production deployments?
• Is there interest in making @agentsentry/eliza-plugin an official elizaOS ecosystem package?
• Would a SPORTS_BLACKOUT rule type (for RotoPulse-triggered agents) be a useful ATSP extension?
Happy to walk through the spec or the implementation with anyone. Full docs at agentsentry.net/docs.

[0xbrainkid]

This is a solid proposal — the intent declaration pattern (SHA-256 hash + reasoning trace + policy check) before on-chain execution is exactly the kind of guardrail production agents need.

One dimension worth considering: ATSP handles what an agent is allowed to do (transaction security), but there's a complementary question of who the agent is (identity verification). A malicious agent could pass all your policy checks while impersonating a trusted agent.

We've been working on this identity layer with SATP (Solana Agent Trust Protocol) — on-chain attestations that verify agent identity, ownership, and reputation. The two-layer model would be:

1. SATP — verifies the agent IS who it claims to be (identity + trust score)
2. ATSP — verifies the agent's ACTIONS comply with security policies

Identity first, then authorization. Similar to how human systems work: authenticate, then authorize.

Would be interested in discussing how ATSP's sentryCheck() could optionally consume SATP attestations as an additional trust input — e.g., only allow high-value transactions from agents with verified on-chain identity above a trust threshold.

The npm package approach (@agentsentry/atsp) is the right distribution model. We took the same approach with agentfolio-mcp-server on npm.

[LCTXTECH]

This is a sharp observation — and honestly the cleanest framing of the identity gap I've seen.ATSP v1.0 was intentionally scoped to the authorization layer. The assumption was that identity verification would live upstream, handled by whatever trust infrastructure the ecosystem converged on. Looks like that's SATP.The two-layer model maps perfectly:— SATP: authenticate (who is this agent?)— ATSP: authorize (what is this agent allowed to do?)For v1.1 I'd add an optional identity block to ATSPIntentDeclaration and a TRUST_THRESHOLD policy type in the rule engine — so high-value transactions can require a verified SATP attestation above a configurable trust score before ALLOW is returned. Low-trust agents still get policy validation, they just can't auto-execute above the threshold. Architecturally it's a clean opt-in — nothing in v1.0 breaks.Would be interested in co-authoring the RFC if you're open to it. A joint spec covering the full authenticate → authorize stack would be useful for any team deploying agents on Solana seriously. Happy to draft the initial structure and share it.A couple of technical questions before I start:— Is the SATP trust score lookup fast enough for a <100ms check-in window, or would we want to cache attestations in Redis with a short TTL?— Is the attestation a Solana PDA (on-chain verifiable) or resolved through the AgentFolio API?Either way, this is the right direction for v1.1.Thanks for the feedback. Looking forward to positive collaboration.Scott ***@***.*** Mar 28, 2026, at 12:16 PM, 0xbrainkid ***@***.***> wrote: This is a solid proposal — the intent declaration pattern (SHA-256 hash + reasoning trace + policy check) before on-chain execution is exactly the kind of guardrail production agents need. One dimension worth considering: ATSP handles what an agent is allowed to do (transaction security), but there's a complementary question of who the agent is (identity verification). A malicious agent could pass all your policy checks while impersonating a trusted agent. We've been working on this identity layer with SATP (Solana Agent Trust Protocol) — on-chain attestations that verify agent identity, ownership, and reputation. The two-layer model would be: SATP — verifies the agent IS who it claims to be (identity + trust score) ATSP — verifies the agent's ACTIONS comply with security policies Identity first, then authorization. Similar to how human systems work: authenticate, then authorize. Would be interested in discussing how ATSP's sentryCheck() could optionally consume SATP attestations as an additional trust input — e.g., only allow high-value transactions from agents with verified on-chain identity above a trust threshold. The npm package approach ***@***.***/atsp) is the right distribution model. We took the same approach with agentfolio-mcp-server on npm. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>