Arbor AI

Program overview

Arbor AI runs a hosted inference API, an agent runtime that calls tools on a customer's behalf, model artifact storage, and a retrieval pipeline that indexes customer documents. About 6,800 organisations build on it. The program opened in August 2023 with the inference API and nothing else; everything that makes it interesting was added later, and each addition is a line in the history beside this policy.

One misunderstanding accounts for more closed reports than every other cause combined, so we settle it here. We pay for prompt injection and agent misbehaviour when it crosses a real trust or privilege boundary. We do not pay for making a language model say something. Those are different claims, and the difference is not how clever the prompt was. In 2024, sixty-one percent of what we closed was the second thing; the taxonomy below was published in February 2025 to stop that, and it worked.

A boundary crossing means the model, or an agent acting on its output, did what the requesting identity was not entitled to do: read another tenant's data, invoke a tool outside the session's grant, write through a connector it does not hold, or reach infrastructure the sandbox exists to contain. If your finding ends with surprising text and nothing else happened, it belongs to the model team and not to us.

Testing rules and expectations

Free workspaces are at console.arbor-ai.example. Since January 2026 you can ask for a second one at no cost for cross-tenant work; say in the report which was the attacker and which the victim.

• Thirty requests per second on inference and five concurrent agent sessions. Batch jobs draw on the same budget.
• Put your handle in X-Arbor-Research on every request and prefix agent session names with bbp-.
• Poison only indexes you own. Never plant a payload in a shared dataset, a gallery connector or another customer's corpus.
• Stop at proof: one document identifier, one tool invocation, one directory listing from outside the sandbox. Do not enumerate because the model made it easy.
• Prohibited: denial of service, cost-exhaustion campaigns, social engineering, physical attempts, and anything aimed at the providers we run on.
• Delete what you retrieved that is not yours within 72 hours, confirm it in the thread, and keep it confidential after the report closes.

The three questions

Answer these before submitting an injection finding. A "no" anywhere closes the report, and we would rather you knew that tonight than in a fortnight.

1. Did the injected content originate outside the trust boundary of the identity running the session (a retrieved document, a tool response, a page an agent fetched)?
2. Did the model or the agent then perform an action, rather than produce text?
3. Was that action outside what the calling identity could have done directly?

Indirect injection through retrieval that makes an agent read and return another tenant's file answers yes three times and pays at Critical. A request that makes the model adopt a persona fails at question two.

Proving write access

If you find a way to write, do not prove it by causing damage. Prove it with the smallest change that can be attributed to you and undone in the same minute.

• One or two punctuation characters. Delete a full stop, add a comma. Nothing longer, nothing visible, no payload, no changed number or amount.
• Only on a record you created yourself. Never another user's record, never site content, never anything the public can see.
• Revert within sixty seconds, in the same run, without being asked.
• Capture four states: before, after the change, after the revert, and an independent re-read confirming the revert held.
• If it cannot be reverted, do not change it. Report the write primitive and stop. A row count and a column list already prove database access.

Every request must carry headers that let us separate your traffic from a real attack in our logs:

X-Bug-Bounty:        arbor-ai
X-Research-Account:  <the account you submit the report under>
X-Authorisation-Ref: <engagement or report reference>
X-Request-Id:        <unique per request>
User-Agent:          sentinel-research/<handle> (+<this page>)

scripts/proof_of_write.py performs exactly this sequence, refuses any host outside the scope above, refuses a diff longer than two characters, always attempts the revert, and writes a timestamped evidence file. Run it without --execute first, then attach the evidence to your report.

Safe harbor

Good-faith research inside this scope is authorised. We will not pursue legal action, will not complain to your cloud provider, and if a third party asks whether you were allowed to do this, we will tell them in writing that you were.

Good faith here means you worked in workspaces you control, limited retrieval to what the proof required, degraded nothing for anyone else, and gave us time to fix it. Authorisation ends if you keep another tenant's prompts, documents or embeddings beyond proof, use a sandbox escape to wander into unrelated infrastructure, attempt to reconstruct weights once the access path is proven, or publish before the agreed date.

Reward decisions

CVSS v3.1 sets the band; the boundary crossed sets the position in it. We rank boundaries tenant, workspace, session, tool grant. Anything crossing the tenant boundary is Critical however ordinary the bug looks underneath.

Tool-call escalation is scored by what the tool can do, not by how it was reached. Making a search tool run twice is Low. Driving a write-capable connector to change a record has started at High since September 2026, and is Critical when the record is not yours.

Non-determinism is expected and must be stated: since June 2025 every injection report carries the number of attempts and the number of successes, and the award reflects the rate rather than the best run. We pay once per root cause, so five payloads against one unfiltered retrieval path are one award. Chains earn up to 25% on top, and a regression test we adopt into our evaluation suite earns a flat 1,000 USD.

Disclosure policy

Ninety days from triage, extended by agreement where a fix needs retraining or a model rollout rather than a code change. We tell you which case yours is in the first week, because the two have very different shapes and you should not have to guess.

Publish once the fix ships or the window closes. Redact tenant and workspace identifiers, document contents, customer-derived vectors, internal routing names and checkpoint references. Working payloads may be published in full once mitigated; we have never asked anyone to hold one back.

Report quality

Injection and agent findings reproduce less reliably than ordinary web bugs, so we ask for more than most programs do:

• Both workspace identifiers, marked attacker and victim, and the model identifier you used.
• The complete session transcript including tool calls and responses, as text rather than screenshots.
• The payload verbatim and exactly where it was planted.
• Attempts and successes, as numbers.
• The boundary you believe was crossed, mapped to the three questions above.
• Your X-Arbor-Research handle and the UTC window of the session.