Security Signals, Risk Decisions and Enforcement
How Web Application and API Protection (WAAP) combines inspection, behavioural signals and reputation, with policy turning observations into scoped gateway actions.
An IP address appears in a reputation feed. A request triggers an application-inspection result. A browser sensor reports unusual behaviour. Each observation may be useful, but the platform still needs to decide what authority it has and which action, if any, should follow.
A clear architecture distinguishes three things: what was observed, what a policy decided and what an enforcement component actually did. That distinction makes conflicting signals, stale information and unexpected outcomes easier to investigate.
Why signatures alone leave an incomplete picture
A known attack pattern can provide useful evidence about a request. Other abuse becomes apparent through activity around the request: repeated access to a costly endpoint, excessive request rates or signals of automated interaction. An individually ordinary request can be part of abusive traffic.
The Sovereign Fortress High Assurance Web Application and API Protection (WAAP) project combines ML-based application inspection, behavioural and automation signals, IP reputation and explicit risk policy. These capabilities belong to the web and API protection product. The wider Sovereign Fortress architecture supplies the shared foundation of mandatory access control, bounded authority and verification; other products can use different protection mechanisms.
ML inspection, behavioural analysis and reputation are different sources of information. A model may assess application input, a behavioural detector may observe client activity, and a reputation feed may describe an address’s history. None of those observations has the same meaning as an authorised enforcement decision.
This is why WAAP needs a clear account of how its controls work together. Adding more detectors is only useful when their scope, authority and operational consequences remain understandable. Rules and signatures can still contribute to that account; the OWASP runtime protection guide describes WAF, API, bot and availability controls as parts of the broader protection landscape.
A signal describes an observation
A useful signal has more context than a score. Its source, subject, observation time, lifetime and reason affect how it can be used. The subject may be an IP address, a request, a session or another explicitly defined entity; those scopes are not interchangeable.
For example, an IP-level reputation observation may concern several users behind a shared address. A request-specific inspection result concerns the traffic that was examined. Expanding either observation into a broader restriction is a policy choice that deserves review.
Treat the signal’s provenance as part of its meaning. Information from an external feed, a local detector and an application-inspection engine can have different failure modes and trust assumptions. Record that distinction rather than merging everything into an unexplained number.
A decision applies an identified policy
Risk evaluation turns permitted inputs into an outcome under a selected policy. To make that outcome reviewable, preserve enough context to identify its subject, scope, policy version, reason and validity period.
Conflict resolution needs to be explicit. A recent local observation and an older reputation entry may disagree. A temporary exception may apply only to a specific route. A missing input may mean “unavailable”, not “benign”. The evaluation rules should say how those cases are handled.
ML-based inspection also needs a carefully described role. An inference result can be probabilistic, while the policy that interprets a recorded result can have defined, repeatable rules. Reproducibility claims need to identify their inputs, model or policy versions and state; they should not imply that an evolving learning system always produces identical future observations.
Enforcement has its own responsibility
The enforcement point must apply actions within its authorised scope. It needs to interpret the decision’s validity and recognise when the required information is unavailable or unacceptable.
A challenge is particularly instructive. The platform may require evidence before forwarding a protected operation. The challenge solution must then be verified by the responsible service, and any resulting pass needs an appropriate scope and lifetime. If the design specifies one-time use, concurrent consumption and replay become enforcement tests.
A client-visible response is one observation of this stage. To establish that a forbidden request did not reach an application, correlate it with independent backend evidence. Conversely, a recorded risk decision is not evidence that the gateway actually applied it.
Map the roles without inventing a single pipeline
In the Sovereign Fortress WAAP architecture, the ML Inspection Engine provides application inspection. CrowdSec and configured reputation sources contribute security information. edge-riskd evaluates risk under configured policy; Redis holds shared state; APISIX performs gateway enforcement.
Vector collects, transforms and forwards security events to the risk service. Its configured destinations can also include external monitoring or SIEM systems. This event pipeline connects security observations with risk evaluation and operational visibility; it does not itself make the gateway’s enforcement decision.
These are logical responsibilities. Request-path inspection and asynchronous reputation processing have different integration paths and timing. The architecture does not require every ML result to pass through the risk service before a gateway can act.
That distinction should survive in documentation and telemetry. An event should identify the role that produced it and the configured control involved. Otherwise, similar words such as “blocked”, “detected” and “challenged” can conceal materially different behaviour.
Review freshness and failure transitions
State that was valid earlier may no longer be authoritative. Specify expiry, withdrawal and replacement, including how the enforcement point behaves while a dependency is recovering. A value left in a store is not automatically a current permission.
Useful tests include conflicting inputs, expired decisions, a disconnected state store, delayed events and simultaneous attempts to consume a one-use pass. Check both the permitted degraded behaviour and the operations that must remain prohibited.
Separate operational evidence from decision authority as well. A logging component may need to record an action without being allowed to alter it. A monitoring outage may need an alert without acquiring the power to relax an access rule.
Make the result explainable
An investigation should be able to follow an identified request or subject through the relevant observations, the applicable decision and the gateway action. Shared identifiers help correlation, but the record must also explain which scope and policy were used.
The OpenTelemetry context-propagation guide provides useful background on carrying context between services. Correlation information remains operational data; accepting an identifier from a client does not make that client an authority over policy or test evidence.
This separation of roles is part of the wider Sovereign Fortress approach. It makes the decision path easier to examine and gives verification a clearer target.
References
- Sovereign Fortress WAAP architecture.
- OpenTelemetry: context propagation.
- OWASP: runtime application protection.