Nexus Shield
Stop malicious requests without handing your application traffic to someone else.
Nexus Shield is a sovereign web application firewall with behavioural protection. It inspects HTTP and API requests at the point of entry, classifies attack behaviour, enforces an action on each request, and keeps the resulting evidence and policy inside your own estate.
- 01
Inspect
Requests examined at the point of entry.
- 02
Classify
Attack behaviour categorised and scored.
- 03
Enforce
Pass, block, deny or drop per policy.
- Self-hosted protection, including air-gapped estates
- SovereignSelf-hosted protection, including air-gapped estates
- Evidence of what was inspected and what was decided
- Request-levelEvidence of what was inspected and what was decided
- Exclusions narrowed to a path, argument or host
- Scoped tuningExclusions narrowed to a path, argument or host
- Ban, captcha and throttle decisions on sources
- BehaviouralBan, captcha and throttle decisions on sources
The problem
Application attacks never stop, and crude blocking is what makes protection get switched off.
Most teams do not lack a firewall in front of their applications. They lack one they trust enough to leave in enforcing mode, with evidence good enough to answer a question afterwards.
The pressure on applications and APIs is continuous
Public services and customer portals absorb automated probing, injection attempts, credential stuffing and scanning every hour of the day. The volume is not an incident, it is the operating condition, and it has to be handled without a person watching a console.
False positives make crude protection unusable
When the only way to clear a legitimate request that trips a rule is to disable the rule across the estate, protection erodes one exception at a time. Teams either block their own users or quietly weaken the ruleset, and neither outcome is written down.
Point protection produces weak evidence
A counter that says how many requests were blocked does not tell you what was inspected, which rule matched, which source repeated the behaviour or who authorised the exception last quarter. That gap is felt during an audit and during an incident.
Protection sits apart from security operations
Request-layer events live in one console and endpoint and identity signals live in another, so a coordinated attack is reconstructed by hand and a response at the request layer is applied manually by whoever happens to have the credentials.
Traffic and telemetry are pushed into a vendor cloud
Many protection services require application traffic, request records and policy to transit or reside in infrastructure the customer does not control. For government, defence, critical infrastructure and regulated organisations, that is a jurisdiction question before it is a technical one.
What Shield is
One request-layer protection product: inspection, policy, scoped tuning and behavioural enforcement.
Shield combines rule-based inspection of HTTP and API traffic with behavioural decisions against the sources behind it, under one policy model, one identity model and one audit record.
On the inspection side, Shield examines requests to protected applications and APIs, matches them against named rulesets, scores anomaly and applies an action ranging from pass through to block, deny or drop. On the behavioural side, it holds active decisions against sources whose conduct warrants a ban, a challenge or a throttle, scoped to an address, a range or wider network context. Both sides write to the same record, so the request that triggered a decision and the decision itself are read together.
Shield is the request-layer product of the Nexus security family. Nexus Sentinel is the security operations layer for detection, correlation, investigation and orchestrated response, and Nexus Edge handles load balancing and traffic infrastructure. Shield does not replace either, and its telemetry is designed to be correlated in Sentinel rather than read alone.
Operational boundaries
Enforcement, not investigation
Shield decides on requests and sources at the point of entry. Correlation, case management and orchestrated response belong to Sentinel, which consumes Shield telemetry and can drive Shield actions under policy.
Tuning narrows, it does not switch off
Exclusions apply to a named rule within a URI, argument or host scope, require a reason and at least one scope, and reconcile into the active protection configuration.
Risk reduction, not perfect prevention
Shield reduces exposure at the request layer and makes each decision visible and reviewable. It is one control in a layered posture, which is why the evidence is built to be correlated.
Request protection workflow
Inspect, classify, enforce, tune, correlate, audit.
The same path runs for every request, whether it passes in milliseconds or becomes the reason a source is banned for the rest of the day.
- 01
Inspect
Every HTTP and HTTPS request to a protected application or API is examined at the request layer before it reaches the application.
- 02
Classify
Behaviour is matched against protection rules and scored, then tagged with a category such as injection, scripting, file inclusion, protocol abuse, scanning or brute force.
- 03
Enforce
An action is applied to the request, from pass through to block, deny or drop, according to the policy in force for that host and path.
- 04
Tune
Known false positives are narrowed with scoped exclusions carrying a recorded reason, so protection is refined rather than switched off.
- 05
Correlate
Request-layer telemetry is available to Sentinel, where it can be joined with endpoint and other security signals into one picture.
- 06
Audit
What was inspected, what was decided, what was tuned and who changed it are held as evidence inside your own estate.
Protection that a team is willing to leave enforcing
Request evidence
What was inspected, what was decided, and what is spiking right now.
A live feed across protection instances shows each inspected request with its action, attack category, source, method, host and path, response status and anomaly score, filterable by action, category and source.
Inspected requests
| Time | Action | Category | Source | Method | Host and path | Status | Score |
|---|---|---|---|---|---|---|---|
| 10:42:18 | Block | SQL injection | 203.0.113.44 | POST | portal.example/gov/search | 403 | 92 |
| 10:42:14 | Deny | Scanner activity | 198.51.100.17 | GET | portal.example/.well-known/probe | 403 | 78 |
| 10:42:09 | Pass | No match | 192.0.2.88 | GET | portal.example/account/summary | 200 | 3 |
| 10:42:03 | Block | Cross-site scripting | 203.0.113.91 | POST | api.example/v2/comments | 403 | 87 |
| 10:41:58 | Drop | Protocol abuse | 198.51.100.203 | POST | api.example/v2/upload | 444 | 81 |
| 10:41:52 | Block | Remote file inclusion | 203.0.113.12 | GET | portal.example/render | 403 | 84 |
| 10:41:47 | Pass | No match | 192.0.2.140 | PUT | api.example/v2/profile | 204 | 6 |
| 10:41:41 | Deny | Credential brute force | 198.51.100.66 | POST | portal.example/auth/login | 429 | 74 |
Illustrative structure of the request audit view with neutral sample data, not a customer environment.
Top categories, inspected traffic
Scanner and bot activity
38%Automated probing across many paths from a small number of sources.
SQL injection attempts
24%Payload patterns against search and reporting parameters.
Cross-site scripting
16%Script payloads submitted through comment and form arguments.
Credential brute force
11%Repeated authentication attempts against a single login endpoint.
Protocol abuse and malformed traffic
7%Requests that break expected structure or headers.
File inclusion and remote code patterns
4%Path traversal and command payloads against rendering endpoints.
Actions
Pass, block, deny and drop are all visible
Categories
Attack behaviour is named, not just counted
Pivot
From a spike straight into tuning
Inspection record
The request that was examined, the category it matched, the action taken, the response status and the anomaly score, filterable by action, category and source.
Policy history
Which ruleset and rule were in force, what was changed, and the reason recorded against every scoped exclusion.
Decision record
Behavioural decisions with their action, scope, origin, reason, creation and expiry, including those lifted by an operator.
Attribution
Identity, role and timestamp for every policy change and manual enforcement action, inherited from the platform identity and audit model.
Rules and tuning
Search the catalogue, narrow the exception, keep the protection.
Protection rules are grouped into named rulesets and searchable by the teams that own the applications. When a legitimate request trips a rule, the answer is a scoped exclusion with a recorded reason, not a rule removed from the estate.
The rule catalogue is searchable, so an application team can find the rule that matched a specific request rather than guessing which part of the ruleset is responsible. Rulesets are named and can be enabled or disabled at the ruleset level where a whole class of protection is genuinely not applicable to an application.
An exclusion is deliberately narrow. It targets one rule and applies within the scope you set, which can be a URI, an argument name, a host, or a combination of them. At least one scope is required and so is a reason, so an exception carries its justification with it and can be reviewed later by someone who was not in the room.
Changes reconcile into the active protection configuration, and the change itself is attributed through the platform identity and audit model. Tuning is a governed operation with a history, not an edit someone remembers making.
Scoped exclusion
Ruleset
Application core protection
Rule
request-argument-injection-pattern
Reason recorded
Structured report filter legitimately submits comparison operators that match the injection pattern. Verified with the reporting service owner and limited to that one argument.
Scope
- Hostportal.example
- URI/reports/generate
- Argumentfilter_expression
- Raised byApplication security engineer
- ReviewRecorded with attribution and timestamp
- EffectOne rule, one argument, one path
An exclusion narrows one rule against a named path, argument or host. Protection stays active everywhere else.
Catalogue
Findable rules
Discipline
Reason and scope are mandatory
Reconciliation
Policy becomes active configuration
Behavioural protection
Rules judge the request. Behaviour judges the source.
Alongside inspection, Shield holds active decisions against sources whose conduct warrants intervention, with an action, a scope, an origin, a reason and an expiry attached to each one.
Active protection decisions
| Action | Scope | Value | Origin | Reason | Created | Expires |
|---|---|---|---|---|---|---|
| Ban | Address | 203.0.113.44 | Policy | Sustained injection attempts across multiple hosts | 10:42 | in 4h |
| Captcha | Address | 198.51.100.66 | Policy | Repeated authentication failures on one endpoint | 10:38 | in 30m |
| Throttle | Range | 198.51.100.0/24 | Operator | Aggressive crawl rate against public catalogue | 09:51 | in 12h |
| Ban | Autonomous system | AS64500 | Operator | Coordinated scanning outside service geography | 08:20 | in 24h |
A decision can ban a source outright, present a challenge before traffic is accepted, or throttle the rate at which requests are served. Scope can be a single address, a range, a country, or autonomous-system context where that is the right unit of judgement for the service being protected.
Decisions raised by policy and decisions raised by an operator sit in the same list with their origin visible, and every decision carries an expiry so protection does not silently accumulate permanent blocks. Operators can create a decision by hand when they see something the policy has not caught, and can lift one when a legitimate user has been caught by it.
Fleet health is visible alongside the decisions, because an enforcement component that is degraded or unreachable changes what a clean decision list actually means.
Enforcement fleet
- Healthy
shield-edge-a1
Request inspection, primary ingress
- Healthy
shield-edge-a2
Request inspection, secondary ingress
- Degraded
shield-enforce-01
Behavioural enforcement agent
- Healthy
shield-enforce-02
Behavioural enforcement agent
Application identity and access
Protection that sits with your access policy, not beside it.
Shield fronts applications that already answer to your identity layer, so the request-layer control and the access control follow the same policy.
Applications protected by Shield participate in single sign-on with multi-factor policies applied through the Nexus identity layer, with federation to directory and SAML sources where an organisation already runs them. Administrative access to protection policy, exclusions and behavioural decisions follows the same identity and role-based access control model as the rest of the platform.
This is a supporting property rather than the centre of the product. It matters because it is what makes a policy change attributable to a person and a role, and what keeps request-layer protection consistent with the access rules the organisation has already decided on.
- Single sign-on
- Applications behind Shield authenticate through the shared identity layer rather than maintaining separate login handling.
- Multi-factor policy
- Second-factor requirements are applied by policy and inherited rather than configured per application.
- Federation
- Directory and SAML federation sources are supported where the organisation uses them.
- Administrative access
- Role-based access control governs who can change protection policy, raise exclusions or lift decisions.
- Attribution
- Identity, role and timestamp are recorded against every administrative action.
Shield and Sentinel
Request-layer protection that the security operations team can see and drive.
Shield emits request-layer telemetry that Sentinel ingests and correlates with endpoint and other signals, and a governed Sentinel runbook can invoke Shield enforcement where policy permits.
Request layer to security operations and back
01
Request
A client request arrives at a protected application or API through your own ingress.
02
Shield
The request is inspected, classified and actioned at the request layer under the policy in force.
03
Telemetry
The inspection record, action and category are emitted as request-layer security telemetry.
04
Sentinel
Sentinel ingests that telemetry and correlates it with endpoint and other signals into cases.
05
Governed response
A runbook decides on a response, pausing for a named authoriser wherever policy requires it.
06
Shield
Where the response calls for it, an enforcement decision such as a ban or throttle is applied back at the request layer.
Context
One source, several signals
Governance
Response carries authority
Separation
Two products, one operating model
Use cases
Where Shield earns its place.
The common thread is protection that has to stay enforcing under real traffic, with evidence and policy that never leave the organisation.
Government
Public-sector internet-facing services
Citizen-facing portals that must stay open to the public while absorbing continuous automated probing, with the evidence of what was blocked kept inside the department.
Regulated
Regulated customer portals and APIs
Financial, healthcare and utility interfaces where request-layer protection has to coexist with strict data residency and auditability obligations.
Enterprise
Internal applications behind controlled ingress
Line-of-business applications exposed through a controlled entry point, protected consistently without rewriting the applications themselves.
Availability
Bot, scanner and brute-force pressure
Sites under steady automated load where behavioural throttling and challenge decisions matter as much as signature matching.
AppSec
Teams that need precise tuning
Application teams that cannot accept broad rule disablement to clear one false positive on one form field.
Sovereign
Disconnected and sovereign environments
Estates with no route to a vendor cloud, where protection, policy and evidence have to function entirely within the boundary.
Why Shield
Precision at the request layer, sovereignty by construction.
Five properties separate Shield from a protection service that decides about your traffic somewhere you cannot inspect.
01
Sovereign by design
Protection, policy and request-layer evidence run inside an estate you control, including air-gapped environments, rather than depending on a vendor tenant to make decisions about your traffic.
02
Precise scoped tuning
Exclusions apply to a named rule within a URI, argument or host scope and carry a recorded reason, so clearing a false positive does not quietly reduce protection everywhere else.
03
Behaviour alongside rules
Rule matching handles the payload. Behavioural decisions handle the source, with ban, captcha and throttle applied to addresses, ranges and wider network context under policy.
04
Evidence and audit built in
The inspection record, the policy history and the decision history are part of the product, not a log export exercise undertaken when someone asks a question.
05
One security operations family
Shield, Sentinel and Edge share identity, governance, approvals and audit through the embedded Nexus engine, so request-layer protection is part of the operating model rather than an island.
Powered by Nexus
Built on the same execution layer we sell as a platform.
Shield is powered by Nexus, the embedded engine that supplies governance, approvals, integrations, secret handling, identity and audit. That is why a protection policy change is attributable, an enforcement action can be gated, and the record of both is held to the same standard as everything else in the estate.
You do not need to buy or implement the Nexus platform to run this product. The shared foundation is why the product deploys into your environment, keeps its data local and produces an audit record you can inspect.
Explore the Nexus platformDeployment and trust
Deployed where your applications are, governed the way your estate is.
Shield runs inside a customer-controlled environment and inherits the platform's identity, secrets, governance and audit model.
- Deployment model
- Self-hosted in a customer-controlled estate, on premises, in a sovereign cloud, or air-gapped where the environment requires it.
- Position in the path
- At the request layer in front of protected HTTP and HTTPS applications and APIs, behind your own ingress and traffic infrastructure.
- Identity and access
- Single sign-on, multi-factor policy, role-based access control and federation to directory and SAML sources, inherited from the Nexus identity layer.
- Secrets
- Credentials used by protection and enforcement components are held in vault-backed storage rather than in configuration files.
- Data residency
- Inspected request records, protection policy, exclusions and behavioural decisions remain inside the organisation's boundary.
- Observability
- Enforcement fleet health, protection state and change history are visible to the team that runs the platform.
- Governance
- Approvals, change attribution and append-only audit come from the embedded platform engine and apply to protection policy as they do elsewhere.
Application security telemetry stays inside the organisation
FAQ
Questions security and platform teams ask first.
Architecture session
See how Shield handles a hostile request, end to end.
A short technical session walks through the inspection feed, a scoped exclusion, a behavioural decision and the evidence each one leaves behind, in a deployment model that stays inside your estate.