Hive Security Risk

hive-security-risk — Security Risk

Assess transaction-time risk — tokens, addresses, approvals, dApps, phishing, simulations — and report severity, evidence, and remediation. Wrong "looks fine" answers here cost users real money, so never conclude safety without a tool-backed check.

Task toolset and identifiers

Toolset: security_risk. Read hive://toolsets/security_risk before execution; it is authoritative for the current output schema, material-call budget, phases, fallback condition, and stop conditions.

Required identifiers depend on the risk object: chain plus token contract, wallet address, spender, dApp URL, or transaction payload. Never invent a spender, owner, calldata, or URL — ask for whatever is missing.

Before choosing endpoints, select exactly one matching entry from the exact workflow's routes[]. Follow its ordered steps, use a fallback only under that step's published condition, stop at four material calls, and preserve the selected route_id in the typed result. The broad coverageCatalog is discovery coverage, not an execution plan.

Procedure

1. Identify the risk object: token, address, approval, dApp, contract, or transaction payload.
2. Call search_tools for the matching security/risk capabilities.
3. Call get_api_endpoint_schema for each endpoint before calling it.
4. Run the narrowest risk check first; add simulation or approval analysis only when the required payload/owner details exist.
5. For Solana, send only the base64 serialized transaction to the GoPlus pre-execution check. Never ask for or forward signing secrets.
6. Report severity, evidence, and remediation steps.
7. Do not provide signing guidance while a critical risk is unresolved.

Bounded calls

• Keep risk checks scoped to the provided contract, address, or payload.
• Avoid broad scans unless the user explicitly asks for an audit.
• Use severity and evidence rather than unsupported certainty.

Worked example

User: "A dApp wants unlimited approval of my USDC (0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48) on Ethereum to spender 0x… — should I sign?"

1. Collect chain, token contract, owner wallet, and spender — all four are required before any approval analysis.
2. search_tools → {"query": "token approval allowance spender risk ethereum", "limit": 5}
3. get_api_endpoint_schema for the approval/address-risk endpoints returned, then invoke_api_endpoint with schema-valid arguments.
4. Report severity and remediation (for example "revoke, or approve a bounded amount") using the template below. If the spender flags critical risk, say "do not sign" plainly.

Report template

## Summary
[Risk level and the safest recommendation in one or two sentences.]

## Calls made
- Toolset: security_risk
- Endpoint(s): [exact endpoint names]
- Identifiers: [chain, risk object, addresses, payload]

## Evidence
- Flags: [provider risk flags with the fields that triggered them]
- Simulation/approval results: [if run]
- Provenance: [provider, fetched_at, observed_at/cache_age_ms, runtime status per call]

## Caveats
[Missing payload, incomplete provider coverage, degraded/rate-limited provider.]

## Next action
[Revoke approval, avoid signing, retry simulation, or provide missing payload.]

Gotchas

• A token can pass metadata checks and still be risky.
• plan_required means the tool exists but cannot run under current upstream credentials — say the check is unavailable, never that the asset is safe.
• Do not provide signing instructions when a critical risk is unresolved.

Evidence receipt (required)

End every Hive-backed answer with a compact receipt built from the _hive object on each material tool response:

• provider, tool, fetched_at, observed_at, cache_age_ms, and runtime_status
• receipt_id, receipt_version, server/build version, and SHA-256 input/result digests when present (self-checks, not signatures)
• source, cache_status, truncated, and any warnings
• canonical chain/entity identifiers plus block, slot, transaction, or query ids present in provider data
• material provider disagreements and how they were handled
• checks that were unavailable, gated, stale, truncated, or intentionally not run
• a claims[] citation from each material statement to exact receipt IDs
• one coverage[] entry for every canonical evidence phase, with each gap explained

Never turn missing evidence into a clean result, silently merge conflicting provider values, or omit a degraded/fallback call from the receipt. observed_at is Hive's first-observation/original cache-population time, and cache_age_ms: 0 only means newly retrieved by Hive. Use provider time, block, slot, transaction, or candle close for source recency; if absent, mark it unknown. Run validate_task_result before presenting the typed workflow result; it checks structure but cannot authenticate an invented receipt.

Runtime status handling

rate_limited and degraded can be retried with backoff. plan_required means the tool exists but the upstream account cannot execute it right now. A blocked check is a caveat in the report, not a clean bill of health.

Hand-offs

• Broader "is this token a good buy" research → hive-token-diligence.
• Wallet-wide activity review → hive-wallet-investigation.
• Solana mint or transaction safety → hive-solana-analysis.