Operations

Security and access

Every simulation starts private. These are the controls, and how to open them up only as far as you need.

IP allow-lists

New simulations accept requests only from the IP address that created them. Add single addresses or CIDR ranges (IPv4 and IPv6, up to 50 entries) in the Access tab, through the API, or with the MCP update_access tool.

update access

curl -X PUT https://api.slurry.io/v1/simulations/acme-projects/access \
  -H "Authorization: Bearer $SLURRY_ACCOUNT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "ipRestrictionEnabled": true,
    "ipAllowlist": ["203.0.113.7", "198.51.100.0/24", "2001:db8::/32"]
  }'

Requests from anywhere else get a 403 before any key checking or data access:

403 Forbidden

{
  "error": {
    "type": "slurry_error",
    "code": "ip_not_allowed",
    "message": "Requests from 192.0.2.44 are not on this simulation's allow-list. Add it under Access in the Slurry dashboard."
  }
}

Using CI runners

Hosted CI runners use large, changing address ranges. Prefer a self-hosted runner or a static egress IP and allow that. If you have to switch restriction off, keep the simulation key in your CI secret store and rotate it regularly - the change is recorded in your audit log.

Keys

Key	Prefix	Used for	Where to create
Simulation key	`slurry_sim_`	Calling one simulation	Returned at creation; more from the Keys tab or API
Account key	`slurry_acct_`	Management API and MCP	Settings, API keys
Webhook secret	`whsec_`	Verifying webhook deliveries	Returned when you add a webhook

All keys are shown once. Slurry stores only a SHA-256 hash and a short prefix for display.
Simulations accept the key as Authorization: Bearer or in X-API-Key.
Account keys carry scopes, and can be limited to IP ranges and given an expiry date.
Revoke a key and it stops working within 30 seconds.

Never put a key in client-side code or a public repository. If one leaks, revoke it and create a new one - revocation cannot be undone and leaves other keys untouched.

Data

Slurry is for synthetic data. Do not upload real personal data, production records, card numbers or credentials, in specs, seed records, instructions or requests. Uploaded content is reviewed automatically, and accounts that break the acceptable use policy are suspended.

Your account

Turn on two-factor authentication under Settings, Security.
Passwords are checked against known breaches when set.
The audit log records sign-ins, key changes, access changes, resets and deletions with time and IP.

Found a vulnerability? Email security@slurry.io. More on our controls on the security page.