# Bento Beta Bounty Feedback Report

## Summary

I tested Bento as a developer trying to connect an AI agent to a pre-execution security layer for Solana actions. The main result is that the official beta flow was blocked at the first required step: deploying/registering a new agent in the Bento dashboard.

This is an important beta finding because Bento's dashboard features depend on a created agent. Without a successfully deployed agent, I could not reach meaningful testing for policies, alerts, action history, monitoring, or human approval flows.

I also tested the npm SDK locally to understand whether the SDK and public API were live. The SDK bootstrap path works, public relayer/config endpoints respond, and the SDK fails closed when no private key is configured. However, the dashboard registration blocker plus SDK documentation inconsistencies made the full end-to-end flow difficult to complete safely.

## What I Tested

- Bento dashboard at `https://app.bentoguard.xyz`.
- New agent deployment flow.
- Agent registration using a connected Solana wallet.
- Wallet behavior during the registration transaction.
- `@bentoguard/sdk@1.2.3` from npm.
- SDK README, TypeScript declarations, and finance sample source.
- Isolated local SDK install on Windows using Node/npm.
- `npx @bentoguard/sdk` setup behavior.
- SDK behavior with no private key configured.
- SDK behavior with a temporary in-memory Solana keypair, without using a real user wallet.
- Public API endpoints:
  - `GET /api/v1/system/relayer`
  - `GET /api/v1/system/config`

I did not submit any private key, did not use a production wallet as an agent key, and did not approve a wallet transaction that was shown as unknown or unsafe by the wallet.

## Dashboard Flow Result

I successfully entered the Bento dashboard. The initial state showed:

```text
No agents connected yet
```

I then opened the agent deployment flow and used:

- Agent name: `CodexBentoTestAgent`
- Agent wallet: the currently connected Solana wallet address
- Daily spend limit: `0.001 SOL`

The wallet had `0.035 SOL` available. That should normally be more than enough for ordinary Solana transaction fees.

However, the registration transaction could not be completed safely. OKX Wallet displayed:

- unknown Solana transaction type,
- unable to parse asset changes,
- insufficient mainnet balance,
- no clear fee, rent, account creation, or asset movement explanation.

The same registration attempt was also tested with another wallet path and still did not work. This made the issue unlikely to be only a single-wallet balance mistake.

Because the agent could not be created, the rest of the official flow could not be tested in the dashboard. Policies, alerts, action history, monitoring, and approval behavior all appear to depend on an existing agent.

## Why This Matters

Bento is a security product. The first transaction a user sees should be highly explainable. In this beta, the first required dashboard action produced a wallet warning that a normal user cannot confidently evaluate.

If the registration transaction is safe, Bento should explain it before the wallet popup:

- what program is being called,
- whether it creates an on-chain account,
- whether rent is required,
- the expected SOL cost,
- whether any funds can move,
- why a mainnet transaction is required during beta,
- and what the wallet should show.

If the registration transaction is not expected to require more than normal gas, then the wallet/builder flow may have a transaction construction or simulation issue.

## SDK And API Findings

### Public bootstrap endpoints worked

`GET https://api.bentoguard.xyz/api/v1/system/relayer` returned live configuration including:

- program id,
- config PDA,
- relayer public key.

`GET https://api.bentoguard.xyz/api/v1/system/config` returned live system config including:

- operator,
- relayer,
- escalate threshold,
- block threshold,
- max strikes,
- total agents,
- maintenance status.

This was a positive signal. The public backend bootstrap path was available and usable.

### SDK fails closed when no key is configured

When initialized with no agent private key and asked to protect a harmless instruction, the SDK stopped with:

```text
Agent Private key not configured. Please set AGENT_PRIVATE_KEY in environment.
```

That is a good security default because the SDK did not proceed without a configured agent key.

### Unregistered throwaway agent reached build-init but failed with unclear HTTP 400

Using a temporary in-memory Solana keypair, the SDK:

- fetched relayer/config data,
- constructed a local simulated transaction,
- encrypted the payload locally,
- generated an action id,
- attempted `/api/v1/actions/onchain/build-init`.

The backend returned HTTP 400, surfaced as:

```text
Request failed with status code 400
```

This is probably related to the agent not being registered, but the error does not say that. For beta testers, this should clearly distinguish between:

- unregistered agent,
- missing owner mapping,
- insufficient funds,
- malformed request,
- unsupported network,
- backend validation failure.

## Main Product Findings

### 1. Agent registration is the critical blocker

The official flow says to get beta access, connect Bento to an agent, explore workflows, and submit feedback. In practice, the product requires agent deployment before the rest of the product can be tested.

In this test, agent deployment was blocked even with:

- a connected wallet,
- matching agent wallet address,
- `0.035 SOL` available,
- daily spend limit reduced to `0.001 SOL`,
- more than one wallet path tested.

This should be treated as a high-priority onboarding issue.

### 2. The first wallet transaction is not explainable enough

The wallet showed an unknown transaction type and could not parse asset changes. A user should not have to guess whether this is safe.

For an AI-agent firewall, this is especially important: Bento's value proposition is trust before execution. The registration transaction should model that same trust standard.

### 3. `protect()` second parameter is inconsistent across SDK materials

The package README and TypeScript declaration describe:

```ts
protect(instruction, signature, options)
```

The second parameter is documented as an Ed25519 signature of the instruction.

However, the finance sample calls:

```ts
protect(input.instruction, input.rawTransaction, ...)
```

The sample comments say Bento receives `instruction + raw unsigned transaction`.

For a product that verifies agent intent before execution, this ambiguity is critical. Bento should make it explicit whether the SDK expects:

- an instruction signature,
- a raw unsigned transaction,
- both,
- or two separate integration modes.

### 4. Risk score scale appears inconsistent

The public config endpoint returned thresholds like:

- `escalate_threshold`: `40000`
- `block_threshold`: `70000`

The SDK on-chain flow maps:

```js
riskScore: verdict.raw_score / 100000
```

The finance sample UI renders the risk score as if it is `0-100`.

If the SDK returns a normalized `0-1` value, the sample may display high-risk actions as visually low-risk. If the intended scale is `0-100000`, docs and UI should reflect that.

### 5. Setup and environment naming need alignment

The `.env.example` uses:

```text
AGENT_WALLET_PRIVATE_KEY
```

The SDK error says:

```text
AGENT_PRIVATE_KEY
```

The setup docs recommend:

```bash
npx @bentoguard/sdk
```

But the wizard prints:

```bash
npx bentoguard
```

These are small inconsistencies, but they reduce confidence during first-time setup.

## Did Bento Increase My Trust In AI-Agent Execution?

Partially. Bento increased my trust in the architectural direction: AI agents that can touch funds need a pre-execution checkpoint, and Bento is aimed at exactly that problem.

However, the current beta did not increase my operational trust enough to use it with meaningful funds yet. The first required dashboard transaction was not wallet-readable enough, and agent registration could not be completed despite a funded connected wallet and a very low spend limit.

## Would I Use Bento In The Future?

I would consider using Bento for agents that can initiate financial or privileged actions, especially agents that transfer assets, call contracts, execute swaps, or interact with production APIs.

I would not use it with meaningful funds until the agent registration transaction is explainable and reliable across common wallets, and until the SDK contract is aligned across README, types, and examples.

## Highest-Impact Recommendations

1. Make agent deployment reliable before anything else.
2. Add a pre-signing explanation for the registration transaction: expected fee, rent, program id, accounts touched, and whether any funds can move.
3. Provide a devnet/sandbox first-test path for beta users.
4. Improve wallet compatibility and transaction simulation across OKX, Phantom, Backpack, and other common Solana wallets.
5. If registration fails, show the real reason instead of leaving the user with a wallet-level "insufficient balance" or "unknown transaction" message.
6. Align README, TypeScript declarations, and finance sample around one `protect()` contract.
7. Clarify whether Bento verifies signatures, raw transactions, or both.
8. Normalize risk score scale across API thresholds, SDK output, docs, and sample UI.
9. Improve HTTP 400 messages during `build-init`.
10. Use one environment variable name and one setup command consistently.

## Final Opinion

Bento is solving a real problem. Autonomous agents should not be able to directly execute irreversible actions just because an LLM produced a plausible instruction.

The beta's biggest weakness is not the product idea. It is the first-mile execution path. The user must be able to create an agent safely and understand the first wallet transaction. Once that is fixed, Bento will be much easier to trust, test, and recommend.