HALO Playground — try HALO on synthetic data

The Playground is a no-commitment way to see HALO work. You get a tenant pre-loaded with a realistic synthetic estate — roughly fifty assets across production, UAT, dev and sandbox environments, and findings covering every class of action HALO can take — plus an API key, in about a minute. No credit card, no connector to configure, nothing of yours to connect.

What makes it different from a demo

Most API sandboxes hand you canned responses. The Playground doesn't. A write you make here goes through the same path a paying customer's write does: the Authority Engine decides, the Action Gateway is the only thing that executes, the Proof Engine verifies closure, and the Flight Recorder records all of it — including the decisions that ended in no action.

What's synthetic is the estate, not the machinery. You are looking at real governance applied to made-up infrastructure, which is the part worth evaluating.

Getting in

Two calls, no authentication on either:

# 1. Ask for a verification token
curl -sX POST "https://<api-host>/api/v1/signup/request" \
  -H 'Content-Type: application/json' \
  -d '{"email":"you@example.com"}'

# 2. Redeem the token that lands in your inbox, asking for a sandbox
curl -sX POST "https://<api-host>/api/v1/signup/verify" \
  -H 'Content-Type: application/json' \
  -d '{"token":"<verification-token>","kind":"sandbox"}'

The second call returns your tenant id and an API key:

{
  "status": "provisioned",
  "tenant_id": "sandbox-pool-3",
  "tenant_kind": "sandbox",
  "partner_api_key_token": "halo_test_..."
}

Copy the key now. It is shown exactly once and stored only as a hash — there is no way to read it back. If you lose it, run the signup again.

Every subsequent call carries it as a bearer token, together with your tenant id:

curl -s "https://<api-host>/api/v1/findings?limit=5" \
  -H "Authorization: Bearer ${ARMOR_TEST_KEY}" \
  -H "X-Tenant-Id: sandbox-pool-3"

See the API overview for the conventions every endpoint follows — pagination, error shape, versioning.

Three things to know before you rely on it

A Playground tenant is shared. There is one small pool of Playground tenants for the whole service and everyone who signs up gets one of them, so you are sharing a tenant rather than being given your own. Your slot is tied to your email address, so coming back brings you to the same one — along with whoever else is in it. That is how the Playground is meant to work; it is what makes it free and instant. What follows from it:

• Treat everything in a Playground tenant as public. Never put real data, real hostnames, or anything you would not publish into one.
• The monthly action and export allowances are shared too. If someone else in your slot has used them up, you will hit the limit without having done anything.
• Your key expires. Playground keys are issued with a short lifetime (7 days by default) and stop working when it elapses. Sign up again for a fresh one — you will get the same tenant back.
• One key at a time. Signing up again replaces your previous key rather than adding to it, so the old one stops working immediately.
• There is a shared request budget. Playground traffic is rate limited per key and across the playground as a whole; a burst gets 429 with a Retry-After, not a ban.
• The playground can be full. If every slot's key allowance is in use, signup returns 503 with a Retry-After. Capacity frees up as keys expire, so try again later.

Coming back later brings you back to the same tenant — your slot is tied to your email address — though whatever you did there may already have been cleared by the nightly reset.

It is wiped and rebuilt on a nightly cycle. Findings and events are deleted outright and the synthetic estate is rebuilt from scratch, with no warning and no undo. That is the point — it stays clean for the next visitor — but it means nothing you do here persists. If you want a scratch tenant that only your team touches, you want a test-mode tenant on a real account instead, not the Playground.

Autonomy is capped. Low-risk ("SAFE") actions run automatically, exactly as they would on a real tenant. Everything above that class is capped at notify-only no matter how the autonomy settings are configured — a structural limit, not a default you can raise. You will see the decision explain itself in its reasoning trail when the cap applies. Similarly, only synthetic connectors can be enabled; there is no way to bind a real vendor credential to a Playground tenant, by design.

What to try

• GET /api/v1/findings — the seeded estate's open findings, by severity.
• GET /api/v1/assets — the ~50 synthetic assets those findings reference.
• Propose an action and watch the decision come back with its full reasoning trail, including why it was auto-approved, queued for a human, or refused.
• Pull the evidence chain for anything that executed.

When you have seen enough

The Playground is for evaluating the model. When you want HALO against your own estate — real connectors, your own isolated tenant, data that survives the night — that is a real account, and a test-mode tenant comes with it for integration work.

Related

• What HALO is
• API overview
• Glossary