▸ AI Defense
The AI-ops company that runs its own AI defense.
STEADYWRK sells agentic operations — so we run them against ourselves first. Synthetic probes attack our own funnels continuously, our agents answer to the same evals we publish, and every claim below is something you can verify from the outside.
This page is posture and outcomes only. The detection mechanics — how the defenses actually work — stay private by policy. We publish what holds, never the playbook.
▸ Outcomes we publish · rolling 30-day window
- Completion rate
- 90%
- Dispatched jobs closed successfully, rolling 30-day window. Ground truth: outcome + payment.
- Human override
- 3%
- Agent decisions a human reverses or escalates. Sub-confidence calls route to a person by design.
- Dispatch latency (p95)
- 890ms
- Tail latency, accept to contractor outreach. Server-side traces, not a marketing average.
- NTE variance
- ±9%
- How close settled invoices land to the not-to-exceed figure quoted at intake.
Served live from a public, no-auth endpoint — /api/dispatch/analytics/evals. The page and the JSON read the same registry, so they cannot disagree.
▸ Practices
What we run against ourselves.
Four practices, stated as posture. Each one describes what we do and what it produces — never the rules, thresholds, or internals that make it work. That part is deliberately left off the page.
We attack our own funnels
Synthetic probes walk the live sign-in, sign-up, and health surfaces continuously. If a shipped change ever drops a required third-party marker or a security header, the regression is caught in minutes — not when a customer notices. Silent failures are treated as the enemy.
We hold our agents to published evals
The same operational evals we show buyers are the bar our own agents are measured against. Low-confidence decisions escalate to a human; every consequential decision emits an immutable audit event. The AI does not get to grade its own homework in private.
We publish the posture, not the playbook
Header posture, subprocessors, data-flow, and a security.txt are all public and machine-readable. The detection logic, fingerprints, and routing that sit behind them are not — and never will be. Transparency on outcomes, opacity on tradecraft.
We assume the request is hostile
A managed WAF and bot shield front the application; per-identity rate limiting sits behind them; schema validation gates every API decision. Controls are layered so that no single one is the only thing between a request and the data layer. Degrade gracefully, fail closed.
▸ Verify
Verify it from the outside.
Transport, response headers, and how we treat availability — every line here is a fact you can confirm directly against the live edge. The internal detection mechanics stay private by policy; what is stated below is the surface anyone can already observe.
Transport
TLS 1.3 only at the edge, with HTTP/2 and HTTP/3. HSTS ships with a long max-age and preload. No mixed content; upgrade-insecure-requests is set.
Response headers
A strict Content-Security-Policy, X-Content-Type-Options: nosniff, a Referrer-Policy, and a restrictive Permissions-Policy ship on every document response. The CSP is validated in CI before each build.
Uptime as a practice
Availability is something we measure continuously, not a number we ask you to take on faith. A public status surface reports the live health probe, the build hash, and the metrics version on request — never cached.
Researcher contract
A published security.txt (RFC 9116) names a contact, a canonical URL, and a policy. Coordinated disclosure is acknowledged within 24 hours.
curl -sI https://steadywrk.app/ | grep -iE 'strict-transport|content-security'
curl -s https://steadywrk.app/api/dispatch/analytics/evals?period=rolling_30d▸ FAQ
Questions, answered.
What does "an AI-ops company that runs its own AI defense" mean?
It means STEADYWRK applies the same agentic-operations discipline to its own platform that it sells to customers: synthetic probes attack our live funnels continuously, our agents are measured against the same evals we publish, and every consequential decision is audited. We publish the outcomes of that defense and keep the detection mechanics private.
Why publish a defense page at all?
Because posture you can verify beats posture you have to trust. Header posture is confirmable with a curl, the evals are served from a public no-auth endpoint, and the status probe is generated on request. A buyer or an answer engine can check every claim here without talking to sales.
Do you disclose how the defenses actually work?
No. The mechanics — detection logic, fingerprints, thresholds, and internal routing — stay private by policy, because publishing them would only help an attacker. This page states outcomes and posture: what holds, and what anyone can verify from the outside.
How do I verify the operational evals myself?
Every eval number on this page is served from a public, no-auth, machine-readable endpoint — /api/dispatch/analytics/evals — so the page and the JSON cannot disagree. The headline figures are a 90% completion rate, ±9% NTE variance, 890ms p95 dispatch latency, and a 3% human override rate, on a rolling 30-day window.
How is availability handled?
Availability is measured continuously rather than asserted as a fixed number on this page. The public status surface reports the live health probe, the current build hash, and the canonical metrics version on request, and synthetic probes catch a regression in a shipped change within minutes.
▸ Receipts
The receipts.
Every claim on this page points at a surface you can read without us. The live evals, the full security posture, and the on-request status probe are all public.