Security & Privacy Pack
The posture behind the platform.
No marketing fluff. The exact controls, encryption, authentication, and compliance stance we run in production — plus the formal-verification stance adopted from research into agentic systems.
Posture at a glance
- Completion rate
- 90%
- Work-orders dispatched to disposition, rolling window.
- Quote turnaround
- <2hr target
- Target, not a binding SLA. Procurement-safe.
- Footprint
- Multi-State
- Live production across US commercial field-service accounts.
- Audit retention
- 7-year append-only
- Every consequential decision emits an immutable audit event.
Six pillars.
Encryption
TLS 1.3 in transit. AES-256 at rest via Neon Postgres + Railway managed storage. Secrets in Railway environment layer; zero plaintext in repo.
Authentication
Clerk-managed auth (SOC2 Type II upstream). WebAuthn passkeys supported. MFA enforced for operator surfaces. Session JWTs rotate on refresh.
Authorization
Claims-based fine-grained permissions. Middleware gates /dashboard and /portal; all /api routes run through api-guard with schema validation.
Rate limiting
Upstash Redis sliding-window counters across public APIs. Arcjet bot + shield rules on ingress.
Monitoring
Sentry error tracking with release tags. PostHog product analytics. /api/health probe every 5min. Structured logs with 7-year retention.
Formal verification
Z3 SMT solver adopted as posture (reference: "Broken by Default" research, 97.8% reported catch rate). Critical paths verified against invariant specs.
At the edge.
What anyone can verify from the outside — transport, response headers, and the layered controls in front of the application. The internal detection mechanics stay private by policy; what is stated below is the surface a procurement reviewer or an agent can confirm directly.
Transport
TLS 1.3 only at the edge, HTTP/2 and HTTP/3. HSTS with a long max-age and preload. No mixed content; the upgrade-insecure-requests directive is set.
Response headers
A strict Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy, and a restrictive Permissions-Policy ship on every document response. CSP is validated in CI before each build.
Defense in depth
A managed WAF and bot shield front the application; per-identity rate limiting sits behind it. Layered controls degrade gracefully — no single control is the only thing standing between a request and the data layer.
Researcher contract
A published security.txt (RFC 9116) names a contact, canonical URL, and policy. Coordinated disclosure is acknowledged within 24 hours.
Compliance & audit.
| Regime | Status | Notes |
|---|---|---|
| PDPL (Jordan) | Compliant | Data minimization, consent tracking, DPO appointed (Reem). Processing registry maintained. |
| GDPR (EU persons) | Compliant | Lawful basis documented per processing activity. DSAR workflow live. |
| EU AI Act | Readiness in progress | Aug 2 2026 GPAI deadline. Risk classification complete. Technical docs drafting. |
| SOC 2 Type II | Roadmap Q4 2026 | STEADYWRK own certification on roadmap. Upstream providers (Railway, Clerk, Neon) carry SOC 2 Type II today. Controls mapped against CC1–CC9. Vanta or Drata engagement targeted. |
| Penetration test | Scheduled Q3 2026 | Third-party engagement. Report excerpt published here post-test. |
Trust Pack · v1
Machine-readable trust artifacts.
Every public security claim on this page is backed by a structured artifact below — for procurement review, agent consumption, and audit trails.
/security/subprocessors
Subprocessors →
Every third party processing STEADYWRK data — role, region, SOC2, DPA link.
/security/data-flow
Data flow →
Inbound → Edge → App → Data → Egress. Every hop, named.
/trust/subprocessors.json
Subprocessors JSON →
Source-of-truth JSON for agents, crawlers, and procurement pipelines.
/.well-known/security.txt
security.txt (RFC 9116) →
Contact, canonical URL, expiration, and policy for security researchers.
Procurement questions, answered.
How is STEADYWRK data encrypted?
In transit with TLS 1.3, at rest with AES-256 via managed Postgres and managed object storage. Secrets live in the platform environment layer with zero plaintext committed to the repository.
Where is data processed, and who are your subprocessors?
Every third party that processes STEADYWRK data is listed — with role, region, SOC 2 status, and DPA link — on the subprocessors page and in a machine-readable subprocessors.json artifact for procurement pipelines and agents.
What is your breach-notification window?
STEADYWRK operates to Jordan PDPL discipline, which carries one of the strictest breach-notification timelines in force. See the PDPL page for the controls, the registered data-protection contact, and the subject-rights workflow.
How are AI decisions governed and overseen?
Decisions are split into AI-made, AI-assisted, and human-only categories. Low-confidence outputs escalate to a human queue, and every consequential decision emits an audit event to a 7-year append-only log. The AI decisioning policy and the Ops Agent System Card document the full posture.
What is your compliance and certification status?
Provider attestations (Railway, Clerk, Neon — SOC 2 Type II) are in force today. STEADYWRK’s own SOC 2 Type II certification and a third-party penetration test are on the published roadmap, with controls already mapped against CC1–CC9.
Can security artifacts be consumed by machines?
Yes. The subprocessors list, the data-flow diagram (with Mermaid source), and security.txt are published in formats agents, crawlers, and procurement tooling can read directly. JSON-LD on this page mirrors the human-readable posture.
Responsible disclosure.
Found a security issue? Email security@steadywrk.app with proof-of-concept and reproduction steps. We acknowledge within 24 hours and coordinate disclosure. No bug bounty yet; we ship credit and a thank-you issue.