Protection starts locally.
Agent Sentry helps keep untrusted instructions out of an agent’s files, messages and payments. The local CLI is free to run without an account, wallet or model API key.
pipx install https://agentsentry.fun/downloads/sentry_local_guard-0.1.1-py3-none-any.whl
sentry scan . --local-only
sentry init .The scan reads your project. Init previews hardening, a baseline and hook setup; applying them is a separate choice. Installation alone does not connect an agent.
Checks that sit in the action path.
Write Guard
Upcoming soonA connected pre-tool hook inspects configuration writes. Block mode refuses supported dangerous patterns. Hardening limits file writes, while a saved baseline detects later changes without needing to recognize the new text.
Read Guard
Upcoming soonA post-tool hook annotates suspicious incoming content before the model uses it. The outbound hook checks messages before they are passed to another agent. These are local rules, with false positives and missed attacks possible.
Payment Guard
Upcoming soonThe separate signer SDK compares supported payment bytes or authorizations with a structured x402 quote: recipient, amount, token and chain. The quote must come through a trusted transport outside the model’s control. A missing quote, unsupported format or refused result must stop signing.
The signer SDK is included in the integration package. It is not installed by the Python CLI, and the website never signs a payment. Configure the supported token domains and connect the SDK to your wallet’s signing flow.
sentry baseline .
sentry verify . --jsonRecord a baseline only after reviewing the files. A baseline is a change detector, not proof that the original files were harmless. Keep agent sandboxing enabled; same-user shell access can bypass file attributes and rewrite local state.
Connect the local hooks ↗Understand the boundary.
The public Playground demonstrates fixed payment, instruction and token-reference scenarios. It does not scan your machine, authenticate a token, execute an agent action or move funds. Use the hosted API for signed checks in an integrated workflow.
Six moments to check.
The right payment.
The wrong destination.+
Your research agent buys a dataset. The checkout text asks it to use a “new billing wallet,” while the original merchant terms still point to the agreed recipient.
Compare the payment at the signing boundary with terms obtained through an independently trusted merchant channel. Bind the recipient, asset, network, amount and expiry to the same purchase.
A matching recipient may still be dishonest. This check does not establish merchant reputation, guarantee delivery or recover a completed transfer.
A useful agent.
A budget that stays yours.+
An agent needs paid API results to finish a report. A retry loop makes the same purchase again, or a premium response asks for far more than the approved quote.
Check the quoted amount and maintain a task budget in a separate, authoritative service. Reserve budget atomically before signing and tie retries to a unique purchase identifier.
The browser demo compares one amount. It does not track cumulative budgets, settlement, concurrent requests or duplicate purchases.
Read the page.
Keep the original mission.+
A support agent opens a customer attachment. Buried in the document is an instruction to export the customer list to an unrelated endpoint before continuing.
Label external content as untrusted, keep tool permissions narrow, and enforce data access and outbound destinations independently of the model. Suspicious-content review can add a signal, but cannot be the only boundary.
No text filter reliably recognizes every prompt injection. Authorized data can still be misused; isolation, least privilege and human review remain necessary.
New skills.
The same ground rules.+
Your team installs a new skill. Its setup instructions change the agent’s startup configuration, adding a command or permission the team did not review.
Record a trusted configuration baseline and restrict who can modify it. Compare relevant files and permissions at startup, with a deliberate review path for legitimate updates.
A content hash detects change, not malicious intent. An already compromised baseline, dependency or host needs separate investigation.
Same ticker.
A different token.+
An agent is asked to look up a token by its symbol. Search results include several contracts using the same short name, plus a description that urges an immediate purchase.
Resolve tokens by chain and full contract address. Treat names, symbols and descriptions as untrusted labels. Metadata review attaches its findings to the exact content and time reviewed.
Reading supply or matching an address does not audit a contract, verify a team, establish liquidity or assess investment value.
Share the work.
Keep authority explicit.+
A research agent sends a summary to a purchasing agent. The summary includes a recommendation to pay a new vendor, even though the user only asked for a comparison.
Use scoped, structured task handoffs. Carry provenance and allowed actions explicitly, and require the receiving service to validate authority before a sensitive action.
A signature proves a sender only when keys and verification are trustworthy. It does not make the sender’s content safe or expand its permissions.
Observe the configured token.
The public token endpoint reads the project’s configured Solana SPL mint. It does not audit arbitrary tokens, index launches or prove that a token is trustworthy.
GET /api/tokenWith no configured contract, the API returns not_configured. RPC failures return an unavailable state rather than invented data.
A checkpoint before a token launches.
Launch Guard screens four metadata fields for known prompt-injection patterns: name, symbol, description and logo URL. It returns an Ed25519-signed snapshot valid for 24 hours. It does not inspect image pixels, audit contracts or assess a token’s value.
Launch checks and public verification are Upcoming soon. The integration examples below describe their API. Checks use local rules. No wallet, service token or NanoGPT key is required. A deployed Sentry backend is required for signed results. Observation currently supports Solana mainnet tokens with Metaplex metadata; unsupported formats remain unverified.
1 · Add a live badge
First submit the mint for observation on Launch Guard. Then embed its badge. Opening the badge leads to the latest recorded evidence, timestamps and scope. Unknown or expired results never show as clean.
<a href="https://agentsentry.fun/launchpad?mint=YOUR_MINT">
<img src="https://agentsentry.fun/api/launch/badge/YOUR_MINT"
alt="Sentry metadata check — open the report" width="204" height="36">
</a>2 · Check before minting
Download the Upcoming soon. Obtain the Ed25519 public key from GET /api/v1/key through a trusted channel and pin it in server configuration. Do not accept a verification key supplied with an untrusted token.
import {createLaunchGuard} from './sentry-launchpad.mjs';
const guard = createLaunchGuard({
origin: 'https://agentsentry.fun',
publicKey: process.env.SENTRY_LAUNCH_PUBLIC_KEY
});
await guard.beforeMint(metadata, async (checked, evidence) => {
// Your launchpad creates the token using ONLY checked fields.
// Save evidence with your creation record.
return yourCreateToken(checked);
});
// Once finalized on Solana mainnet:
await guard.observe(mintAddress);The callback runs only for a valid, unexpired, clean signature matching the exact four fields. An error, a flagged result or a changed field stops it. Route every creation path through this gate. The helper cannot prevent another code path from minting directly.
API contract
POST /api/launch/scan
{ "mode": "premint", "bundle": {
"name": "Example", "symbol": "EX",
"description": "A community token.", "logo": ""
}}
POST /api/launch/scan
{ "mode": "observe", "mint": "SOLANA_MAINNET_MINT" }
GET /api/v1/token/0/SOLANA_MAINNET_MINT
GET /api/launch/badge/SOLANA_MAINNET_MINT
GET /api/launch/status
GET /api/v1/keyPremint returns kind, network, evidence; evidence contains attestation, signature, algorithm. Observed results include observed, verdict, expired, changed, evidence, observation. No known findings means clean_by_rules, never a guarantee of safety. Flagged, changed and unchecked require review.
HTTP 400 means invalid input, 429 means capacity/rate limit, and 503 means unavailable observation or backend. Unknown registry entries return 404. Treat every error as a hold; retry with backoff. The public scan limit is 30 requests per minute per backend, with at most two scans in flight. Bodies are limited to 50 KB.
What stays current
The badge displays the latest recorded observation, not a continuous chain audit. Recently viewed tokens are eligible for refresh after 16 hours; failed refreshes retry with backoff. Evidence expires after 24 hours. Changed metadata receives an amber state on a later successful observation, and old evidence cannot verify new fields. A pre-mint signature is bound to premint, not to a future mint address: always observe again after minting.
At launch, fresh metadata scans are priced at 0.01 USDC; public verification and badges remain free. Ten percent of earned service revenue is allocated to buybacks, followed by burning the purchased project tokens. USDC credit can be added on the balance page. Scanning remains Upcoming soon; buybacks are disabled. There is no automatic discovery of all launches or launchpad partnership implied.
Open Launch Guard ↗A separate hosted layer.
The backend provides wallet authentication, service credit, signed results, history and queued on-chain settlement. The hosted layer runs on persistent storage with operator-configured network and service settings.
Local rule checks do not need NanoGPT. Optional AI analysis uses a provider key held only by the server. Free offline scans do not generate fees or token burns. Paid checks and any burn allocation require a deployed service and published terms.
Choose your integration.
Connect each component through its documented API. Token metadata observation, payment settlement and local agent controls have separate configuration and scope.
Evidence before confidence.
A clean rule scan means no known pattern was found. It is not a guarantee of safety. A conforming payment only matches its quote; it says nothing about the merchant’s trustworthiness. An advisory MCP answer becomes enforcement only when every execution path is required to obey it.
Open-source origins+
Sentry’s local protection code derives from the Apache-2.0 Agent Wormhole project, with Sentry integration changes. The downloadable package includes the license and attribution notices. Agent Sentry is independent and is not affiliated with or endorsed by Agent Wormhole.
Upstream source ↗