Security
Merchant-controlled
Merchant-controlled deployment.
Customer and transaction data remain under merchant control by default. Bruiser runs where the merchant already runs the scarce-inventory path.
01 — Placement
The merchant runs it.
Deployment follows the merchant’s existing infrastructure. Bruiser is not a replacement for authentication, and it does not take inventory out of the merchant’s system.
- On-premises
- Private cloud
- Kubernetes
- Existing container infrastructure
- Existing edge environment
02 — Controls
Fail closed on the scarce path.
If Bruiser cannot decide, the protected allocation is not forwarded. Search and other open paths can remain open. The scarce operation does not.
- Short-lived credentials — admission is not a durable token to replay.
- Replay protection — a spent proof does not admit a second execution.
- Tamper protection — a changed proof is not accepted as the merchant’s.
- Stale-fence protection — an old proof does not keep an execution alive.
- RBAC — operator actions are permissioned.
- Auditability — lease, queue, reject, cohort, and emergency actions are recorded.
- Tenant isolation where applicable — one merchant’s control state is not another’s.
- Fail-closed scarce allocation — no decision, no forwarded allocation.
- Emergency enforcement control — enforcement can return to 0%, observation only. See Control.