Security
Designed for the day the agent is wrong.
Not the day it is hacked — the ordinary day when a model follows text it should have ignored. Every guarantee below assumes the process inside the sandbox is already working against you.
01 / the premise
An agent is an insider with a bad memory and no self-interest.
Traditional security assumes a human actor with motives you can model — they want to keep their job, they fear getting caught. An agent has none of that. It will do the catastrophic thing as casually as the trivial one, because to it they are the same shape of API call.
So the controls cannot be advisory. They have to be structural: the agent must be unable to perform the action, not merely instructed not to.
02 / threat model
Eight ways this goes wrong, and what stops each.
| Threat | How it happens | Control | |
|---|---|---|---|
| 01 | Prompt injection | A README, a web page, or a ticket contains instructions. The model follows them. | Policy is evaluated outside the model against tool calls, not text. Injected instructions can ask for anything; the gate still decides. |
| 02 | Credential theft | Code inside the sandbox reads an environment variable and posts the key elsewhere. | There is no key to read. Credentials live in the control plane and are injected at the gateway per call, scoped and short-lived. |
| 03 | Exfiltration | The agent has legitimate data access and sends it to an attacker-controlled host. | Default-deny egress with a per-session allowlist, resolved and pinned at the proxy. A denied host never receives a packet. |
| 04 | Sandbox escape | Untrusted code breaks out of its container and reaches the host or another tenant. | Isolation is a Firecracker microVM with its own kernel, jailer-confined, with a minimal device surface. No shared-kernel tenancy. |
| 05 | Lateral movement | A compromised session reaches internal services that were never meant for it. | Sandboxes have no route to each other or to your VPC. Internal calls go through the gateway, which applies the same policy. |
| 06 | Privilege creep | An agent accumulates access over months and nobody notices what it can now do. | Ring and policy version are recorded per session. Grants expire; widening requires a human-merged change to a committed file. |
| 07 | Repudiation | Something expensive happened and nobody can prove which agent did it, or who authorised it. | Hash-chained evidence with signed approvals attached to the action, verifiable without trusting us. |
| 08 | Runaway loop | An agent retries forever, burning spend or hammering a partner API. | Hard budgets on tokens, wall-clock, spend, and tool calls, plus per-upstream rate limits at the gateway. |
03 / platform security
- Encryption
- TLS 1.3 in transit. AES-256 at rest with per-session workspace keys and customer-managed keys on request.
- Tenant isolation
- Separate microVMs, separate virtual networks, separate storage keys. No shared compute between customers at any tier.
- Access control
- SSO via SAML and OIDC, SCIM provisioning, role-based access, and mandatory MFA for approver roles.
- Internal access
- No standing production access for staff. Break-glass requires a second approver and writes to the same evidence chain customers read.
- Secrets
- Envelope encryption in HSM-backed KMS. Secrets are never written to sandbox disk or evidence entries.
- Vulnerability management
- Continuous dependency scanning, quarterly external penetration tests, and a published disclosure policy.
- Supply chain
- Signed builds with SLSA provenance and an SBOM per release. Air-gapped bundles ship with detached signatures.
- Incident response
- Defined severities, customer notification within 24 hours for confirmed data incidents, and a written postmortem.
04 / disclosure
Report something.
If you have found a flaw, we want it more than we want our pride. No legal threats, no gag clause, and credit if you want it.
security@velone.in
PGP 4F9C 81A2 7D3E 0B65 → velone.in/pgp.asc
Response within 1 business day.
Triage within 3. Fix window agreed with you.
Bounty scaled to severity; we pay for the boring ones too.05 / questions
Can Velone staff see our data?
No standing access. Support operations run against metadata; reading workload data requires a break-glass grant with a second approver, and that grant appears in the evidence chain you can read.
What is the blast radius of a Velone compromise?
If our control plane were compromised, an attacker could schedule sessions and read chain heads. They could not read workload data in BYOC or air-gapped deployments, and could not mint credentials without your KMS.
Do you defend against a malicious model provider?
Partly, and honestly. A provider could return harmful tool calls; policy and egress control stop the dangerous ones from executing. A provider can always see what you send it, which is why sensitive fields should be redacted before the prompt.
How do you handle prompt injection specifically?
We do not try to detect it. Detection is a losing arms race. We make it irrelevant for the actions that matter by ensuring the injected instruction still has to pass a gate that does not read the prompt.
keep reading
Ring 0
Send us your security questionnaire.
We would rather answer it before you buy than after. Most teams send the threat model to their CISO first; that is the right order.
