A control you can see before you let it enforce.
Ward is a self-hosted runtime security control for web applications and APIs. It sits inline in your request path and selects one of four customer-controlled actions for every inbound request.
Ward evaluates every inbound HTTP request before it reaches the application. Each decision is annotated with reason codes, a risk indication, and the investigation metadata operators and auditors need after the fact.
Runtime decisions are written to your own evidence store; control-plane actions such as policy changes and rollout decisions are recorded in a durable control-plane audit store. Both stay under your control.
By default, no runtime traffic, decision logs, or audit data is sent to the vendor. Exports to a SIEM, identity provider, or other internal systems remain your decision and your responsibility. You keep ownership of infrastructure, policy, retention, and operational control.
Designed for gradual rollout
Ward is built to be introduced without operational risk. Run in shadow to collect decisions without affecting production, in alert_only to validate signals and operator workflows without blocking, and in strict only where the evidence and operational risk support active enforcement. You can return to a non-blocking profile at any time during major changes or incidents.
Volumetric network attacks that saturate your internet link must still be handled upstream by a CDN, anycast provider, or scrubbing service. Identity, infrastructure hardening, vulnerability management, and incident response remain your responsibility.
Recommended starting point
A scoped pilot on one representative service in shadow mode, lasting long enough to produce a usable decision-log sample. Pilot outcomes — including measured latency overhead and false-positive rates against your real traffic — then drive any decision to widen the deployment.
The attack is rarely one request. It's behavior over time.
Application-layer attacks have shifted away from single payloads and toward behavior over time — abuse that is only visible when sessions, flows, and frequencies are evaluated together.
A login form is probed slowly with credentials drawn from breach corpora. An API is mapped one route at a time by an automated scanner that respects rate limits. A scraper rotates session tokens to stay under the radar of static thresholds.
Each individual request can look ordinary. The abuse pattern only appears when you look across the session.
Why static rules alone are not sufficient
Static rules — pattern lists, signature feeds, regex-based WAF policies — still catch known payload shapes and have a place in defense. But they struggle with three classes of abuse that are increasingly common:
Attackers respect rate limits, mimic real-user pacing, and spread reconnaissance over days. Each request looks unremarkable.
Against well-formed login flows. Inputs are syntactically valid; only the pattern of attempts is anomalous.
Automated data harvesting, fraud activity, and business-logic abuse whose payloads look exactly like real traffic.
Static rules produce false positives the team cannot easily explain. Over time trust erodes: rules get disabled, exceptions accumulate, protection narrows.
What security leadership actually needs
CISOs and architecture reviewers ask consistently for three properties in any new control.
Every decision should map to a reason a human can understand, defend in conversation with application owners, and present to an auditor after the fact.
In regulated industries and data-sovereignty regimes, sending traffic, logs, or behavioral data to a vendor cloud is often not an acceptable trade-off. The control must be operable without that dependency.
Inline controls that can only run in active-blocking mode are difficult to introduce without operational risk. Leadership wants to see before committing to enforce.
An inline decision, a written record, every request.
Ward evaluates every inbound HTTP request inline, before it reaches the protected application — and records what it decided and why.
Your existing proxy or policy enforcement point sends a sub-request to Ward. Ward responds with one of four actions, the request continues or is stopped accordingly, and a decision record is written to your runtime evidence store.
The four actions
| Action | What happens to the request | Typical use |
|---|---|---|
| Allow | Passes unchanged to the application. | Default for legitimate traffic |
| Block | Stopped with a configurable response. | Clear injection attempts, known-bad signatures |
| Rate-limit | Slowed, denied, or signalled to the proxy according to policy. | Bursty abuse, automation suspected |
| Challenge | Client must complete an interactive proof. | Suspected automation where outright block would be too aggressive |
The challenge action is a deliberately middle path. It raises the cost for attackers without rejecting legitimate users who happen to match a risk signal. Browser clients can complete a browser-based proof-of-work flow; native API clients require client or gateway integration with Ward's challenge protocol.
What every decision carries
- A risk score between 0 and 1, derived from the engine's signals.
- One or more reason codes describing why the decision was made.
- A taxonomy mapping to recognized frameworks — OWASP categories, MITRE ATT&CK techniques — where applicable.
- The active profile at decision time —
shadow,alert_only, orstrict. - A request identifier tying the decision to the application's own logs, enabling end-to-end investigation.
- The route, timestamp, and contextual metadata required by audit.
What Ward is not
Decisions are produced by a combination of deterministic rules, behavioral signals, anomaly detection, and policy — each layer is inspectable, and the final action is chosen by customer-controlled policy. Optional LLM-based summarization for operator triage is available, but it is not part of the decision path: a separate, opt-in feature that supports the operator, not the runtime block/allow choice.
Ward is also not a CDN, a load balancer, or a full identity stack. It is a runtime security control that fits inside your existing topology, not a replacement for it.
One hot path, everything else asynchronous — and all of it yours.
Ward consists of an inline engine and a small set of supporting services, all running inside your network. Nothing in the request path depends on the vendor.
Components
Design choices
The hot path makes only fast, predictable decisions. Deeper analysis runs in the analyzer and feeds signals back later — so a slow analyzer never blocks production traffic.
Decisions and signals go to the Analytics Store; desired state, lifecycle, and audit go to the Control-Plane Store. You control retention, backup, and any export. The vendor pulls from neither.
Desired state is compiled into signed bundles. The policy engine verifies integrity before activation; tampered bundles are refused. The hot path needs no per-request database lookup.
Kubernetes is the primary reference; VM-based and other customer-operated patterns are supported. Packaging differs by model — the logical components and control model do not.
Layered defense, not a single decisive technique.
Ward combines multiple layers of signal. Each layer is inspectable, and the final action is the output of policy applied to those signals — never a single model's verdict.
The layers
Pattern lists for known attack classes — SQL injection, XSS, command injection, traversal patterns. Fast and precise where the attack is structurally visible.
Detects patterns static rules miss: unusual request pacing, improbable parameter distributions, route-traversal anomalies.
Looks at how a session moves over time — which routes are touched, in what order, with what velocity. Catches low-and-slow probing and multi-step abuse that no single request reveals.
Customer-controlled rules that combine the above into a final action. Policy is where the trade-off between false positives and missed attacks is made explicit.
Why this matters for explainability
Because the action is the output of policy applied to signals, every decision can be traced back to the inputs that produced it. A reason code identifies the signal class; the policy bundle identifies the rule that mapped that signal to the action. Both are available in the decision log.
Example threats and abuse patterns
| Pattern | How Ward responds |
|---|---|
| SQL injection / XSS / command injection | Deterministic rules, typically Block |
| Automated route probing | Behavioral signals + rate limits |
| Credential stuffing | Session velocity + Challenge |
| Scraping / bot traffic | Behavioral class + rate-limit or challenge |
| Unusual session navigation | Flow analysis + risk-weighted policy |
| HTTP-layer DoS | Rate limits + challenge to raise attacker cost |
| Volumetric network DDoS | Out of scope — handled upstream by CDN / scrubbing |
The DDoS row is deliberate. Ward addresses application-layer abuse; volumetric attacks at the network layer require an upstream control with the capacity to absorb the traffic before it reaches your link.
Posture observation and SDK enrichment
Ward's runtime position also creates a natural foundation for posture observation of the protected application surface. Because Ward already sees traffic flowing through the customer-controlled proxy path, it can use passive evidence from real requests and responses to build a route-aware view of what the application actually exposes in production.
This capability is intended to complement, not replace, request-time protection. Passive posture observation can highlight signals such as newly observed routes, routes that appear outside the declared API surface, missing or weak response security headers, risky cookie attributes, broad CORS behavior, cache settings on sensitive responses, unusual status-code patterns, and differences between observed traffic and expected application behavior.
Where you choose to instrument with the Ward SDK, the application can provide its own context — route ownership, service identity, deployment version, route type, expected authentication requirement, data sensitivity, tenant-boundary expectations, and business criticality — so that posture findings are prioritized accurately and routed to the right owners.
For example, a missing security header on a static asset may be low priority, while the same pattern on an authenticated account route may be more important. A newly observed route may be informational if it is declared by the SDK or OpenAPI inventory, but higher priority if it is unknown, sensitive-looking, or inconsistent with policy.
The runtime architecture naturally supports posture observation, and parts of the signal foundation may already exist — but customer-facing posture findings should be enabled and scoped explicitly per deployment. It identifies exposure and configuration weaknesses from traffic Ward already observes; it is not a claim to detect all CVEs or to replace SCA, SBOM, container scanning, active DAST, or your vulnerability-management processes.
By default, nothing leaves your network.
Runtime decisions, signals, and audit data are written to stores you own and operate. The vendor pulls from none of them.
| Data type | Handling | Leaves network? |
|---|---|---|
| Runtime decision logs | Customer runtime evidence storage (the Analytics Store) | No |
| Runtime signals and events | Customer runtime evidence storage (the Analytics Store) | No |
| Control-plane audit logs | The durable Control-Plane Store | No |
| Policy and rollout state | The durable Control-Plane Store | No |
| Short-lived raw content | Only for active investigation, time-bounded | No |
| Identifiers | Masked or hashed by default | No |
What is collected
- Decisions — action, risk, reason codes, profile, route, request identifier.
- Signals — behavioral and flow-analysis signals, stored alongside decisions.
- Control-plane audit — operator actions, policy and config changes, rollout changes, access-controlled operations.
- Short-lived raw content — retained for a customer-configured window, then removed.
What is not collected
- No browsing history beyond the protected request path.
- No content from requests that were not the subject of an active investigation.
- No data exported to vendor systems as part of standard operation.
Customer-configured integrations
You may choose to integrate Ward with internal systems — SIEM ingestion of decisions, identity-provider integration for operator access, alerting webhooks. These integrations are configured by you and remain your responsibility. Each is opt-in.
Updates
Software updates are pulled by you under your own change-management process. The vendor does not push runtime changes into your environment.
Built to be reviewed as a control, not only used as a tool.
Access is role-based, policy is signed, and every operator and control-plane action is written to a durable audit store you can correlate against runtime evidence.
Access
- Role-based access control with fine-grained permissions: who can view decisions, who can change policy, who can administer the deployment.
- Identity-provider integration is supported where you configure it.
- Operator and control-plane actions are written to the durable control-plane audit store; runtime decisions and security evidence to the analytics/evidence store. Together they let investigators correlate what was decided in traffic with who changed policy, configuration, or rollout state.
Policy lifecycle
- Policy is shipped as signed bundles whose integrity is verified before activation.
- Unauthorized or tampered bundles are refused.
- Activation, rollback, and review are all auditable actions.
Audit and reporting
- Runtime decision evidence supports SOC triage, incident investigation, and regulatory reporting.
- Control-plane audit records show who changed policy, configuration, rollout state, or access-controlled settings.
- Investigations can correlate runtime evidence with control-plane changes to answer both "what happened in traffic?" and "what changed in the control plane?"
- Retention is controlled by you.
The deployment model changes packaging — not the control model.
Ward is deployed into your own environment using a supported self-hosted pattern. Kubernetes is the primary reference; VM-based and other customer-operated models are supported.
A standard deployment includes the inline engine, policy engine, analyzer, control plane, State Store, Analytics Store, Control-Plane Store, and the operator dashboard. In Kubernetes these are deployed into your namespace or cluster boundary. In VM-based deployments, the same logical components run as services on customer-operated infrastructure. Either way, runtime traffic, decision evidence, policy state, control-plane audit, and analytics data remain under your control.
| Deployment model | Typical use | Notes |
|---|---|---|
| Kubernetes | Containerized environments | Primary reference model; namespace-scoped deployment and standard orchestration patterns |
| VM-based | No Kubernetes, or appliance-style requirements | Same logical components run as customer-operated services |
| Other self-hosted | Regulated or constrained environments | Packaging and operations agreed as part of deployment scope |
Profiles
| Profile | What it does | When to use |
|---|---|---|
shadow | Records every decision; takes no action on traffic | Pilot phase; major changes; incident response |
alert_only | Records decisions and emits operator alerts; takes no action | Validation of signals and workflows |
strict | Records decisions and enforces the chosen action | Confident operation after pilot evidence |
You can switch back to shadow or alert_only at any time during major changes or incidents. This is a configuration change, not a re-deployment.
Recommended rollout pattern
On a representative service, with no effect on production traffic.
Long enough to produce a usable decision-log sample.
Address false positives at this stage rather than under enforcement pressure.
Validate operator workflows without blocking.
Where the evidence supports it and the application's risk tolerance accepts active enforcement.
Keep the option to return to a non-blocking profile during major changes or incidents.
Canary patterns are supported and recommended for sensitive services.
What Ward does today, and what needs complementary controls.
Ward is transparent about its scope. The application layer is its job; several adjacent responsibilities remain yours, and a small number of items are explicitly roadmap.
What Ward addresses
- HTTP and application-layer abuse: injection, automation, credential stuffing, scraping, abuse-flow patterns, route-level reconnaissance.
- Audit and evidence requirements at the application layer.
- Data sovereignty for runtime decision data — operational data does not leave your network.
What requires complementary controls
- Volumetric network attacks must be handled upstream by a CDN, anycast provider, or scrubbing service.
- Identity and authentication — Ward consumes identity signals where integrated but does not replace the identity stack.
- Infrastructure hardening, secrets management, backup, monitoring, and end-user SLA remain your responsibility.
- Vulnerability management and incident response remain your responsibility.
What is roadmap rather than delivered
These are not presented as delivered functionality. This document distinguishes them so review is grounded in what exists today.
- Full mTLS across all internal channels — a target-architecture item where not already implemented.
- Customer-facing packaging of internal validation tooling — red-team disclosure gate, policy-validator pipelines, replay-harness. A future option; these tools support the vendor's own release quality today.
Latency
Latency overhead is designed to be low and predictable. Concrete p95/p99 figures depend on your environment, request shape, and traffic patterns, and are produced during your shadow pilot. This is a deliberate choice: a vendor-bench number rarely survives contact with real traffic.
One service, shadow mode, real traffic.
A scoped pilot on one representative service produces the evidence that drives every later decision — including whether to widen the deployment at all.
Pick one representative service and install Ward in shadow. No effect on production.
Run long enough to produce a usable decision-log sample against real traffic.
Work with application owners to address false positives before any enforcement pressure exists.
Move to alert_only to validate operator workflows and alerting.
Move to strict only where the evidence supports it and risk tolerance accepts it.
Retain the option to return to a non-blocking profile during major changes or incidents.
What the pilot measures
- Measured latency overhead (p95/p99) against your real traffic.
- False-positive rates against your real traffic.
- Operator workflow validation in
alert_only. - Decision explainability in practice — can a block be defended to an application owner and an auditor?
Pilot outcomes drive any decision to widen the deployment. Canary patterns are recommended for sensitive services.
This section consolidates the pilot guidance referenced in §1, §8, and §9.
Questions security reviewers ask.
Answers consolidate statements made elsewhere in this document; section references are noted.
Does any of our traffic or logs leave our network?
Can we run Ward without blocking anything at first?
shadow records decisions with no action on traffic; alert_only adds operator alerts with no action; strict enforces. You can switch back at any time — it is a configuration change, not a re-deployment.§1 · §8How do we justify a block to an application owner or auditor?
Is this a black-box AI?
Does Ward protect against DDoS?
What about latency?
How is Ward deployed, and who pushes updates?
What is roadmap rather than delivered?
A representative anonymized record.
Illustrative shape of a single decision as written to the runtime evidence store. Identifiers are masked or hashed by default.
{ "request_id": "req_8f3c0a91d2e4", "timestamp": "2026-03-11T09:42:17.318Z", "route": "POST /api/v2/auth/login", "action": "challenge", "profile": "alert_only", "risk_score": 0.82, "reason_codes": ["credential_stuffing_pattern", "session_velocity_anomaly"], "taxonomy": { "owasp": "API2:2023 Broken Authentication", "mitre_attck": "T1110 Brute Force" }, "signals": { "session_velocity": 14.2, "distinct_credentials": 37, "window_s": 60 }, "identifiers": { "client_net": "203.0.113.0/24 (masked)", "session": "sess_… (hashed)" }, "policy_bundle": "bundle_2026-03-09_rev7 (signed)" }
How each field maps to the decision model
challenge under alert_only, so the record is written but no traffic is affected.