Security and data handling for AI deploy gates.
Shaker turns AI and application security tests into release decisions. This page documents the controls that make those decisions useful to CI, AppSec, customers, and auditors.
Signed AI Gate evidence
AI Gate policy evidence can include signed attestations bound to tenant, target, environment, probe pack, policy, decision, evidence hash, and source-control scope.
- Evidence artifacts include SHA-256 evidence hashes.
- AI Gate attestations are externally verifiable through the public key and verifier APIs.
- CI can reject a decision when the signed scope does not match repo, branch, commit, target, environment, probe pack, or decision.
Raw and redacted evidence split
Shaker separates operator-facing raw artifacts from customer-shareable redacted evidence wherever AI Gate transcripts and worker artifacts are available.
- Raw artifact access is restricted to workspace owners and admins.
- Redacted evidence remains available for normal evidence review and audit workflows.
- Evidence packets are designed for security questionnaires without requiring raw transcript exposure.
No training on customer data
Customer scan inputs, transcripts, targets, credentials, findings, evidence, and approval records are not used to train foundation models.
- Opt-in semantic judging is used for scan evaluation only.
- Credentials are handled as secrets and are not persisted in docs, examples, or shareable evidence packets.
- Customer evidence is retained according to the active plan or contract.
Target authorization and ownership controls
Higher-trust workflows require target ownership, tenant membership, API scopes, and plan entitlements before scans or deploy-gate decisions can run.
- API keys are tenant-scoped and checked against route-level scopes.
- Domain verification raises trust for stronger DAST workflows.
- AI target ownership verification is available for saved AI targets.
Scoped approval tokens
Approval tokens are short-lived signed permits for downstream deploy systems and are issued only from allow decisions or active approval overrides.
- Tokens can be audience-bound for systems such as GitHub Actions.
- Token records are stored for revocation and audit history.
- Blocked decisions do not mint approval tokens.
Private workers and custom retention
Private workers, custom retention, and advanced deployment controls are reserved for enterprise or private-control-plane customers.
- Self-serve customers use hosted worker infrastructure.
- Enterprise customers can negotiate custom data residency, retention, worker isolation, and support commitments.
- SOC 2 audit work starts when customer demand or revenue justifies the formal audit.
Data Handling
What customers can expect
Shaker stores what is needed to run scans, reproduce decisions, verify attestations, support audit review, and enforce approval workflows. Raw evidence is treated as sensitive operational data.
Stored in tenant-scoped records. Secrets are never shown again after creation and should be supplied through secure environment or credential storage.
Used to produce findings, policy decisions, evidence hashes, and redacted audit artifacts. Raw access is restricted.
Designed for customer security reviews. They include release scope, policy, probe pack, decision, evidence hash, attestation links, top findings, reliability signals, and approval state.
Retention depends on plan or contract. Public packaging starts with short retention on free tiers and longer retention on paid plans.
Hosted deployments use US-region VPS, Supabase, AWS worker infrastructure, billing, email, worker, monitoring, and AI-provider services. The subprocessor page tracks the production vendor categories used for customer data.
Formal Compliance
SOC 2 is not currently claimed.
Shaker is building toward the controls customers expect: least privilege, change management, incident response, retention controls, logging, and vendor inventory. Formal SOC 2 work begins when customer demand or revenue justifies the audit.
Incident Response
Clear handling for security and availability events.
The public commitment is simple: classify impact quickly, preserve release evidence, communicate customer action clearly, and keep status updates separate from private investigation details.
Review admin health, worker callbacks, billing/webhook events, status checks, abuse signals, and vulnerability reports to classify severity and affected tenants.
Customer-impacting incidents should be acknowledged on the status page or directly to affected customers after initial triage.
Limit affected scan paths, rotate exposed credentials, preserve audit logs, evidence hashes, callback records, and deployment history before destructive cleanup.
Customers should receive clear impact scope, whether evidence integrity was affected, and any action needed on their side.
Restore service from known-good config, replay safe callbacks or artifacts when needed, verify signed attestation paths, and confirm billing/usage event integrity.
Resolution updates should include recovered functionality, remaining degraded surfaces, and any skipped or manually replayed workflow.
Record timeline, root cause, tenant impact, evidence impact, remediation, owner, and follow-up controls in the private diligence folder.
Material incidents produce customer-facing updates once facts are stable and notification obligations are assessed.
Last updated: May 1, 2026
Draft commercialization surfaces for customers reviewing authorization, data handling, vendors, disclosure, and service terms.