Every allowed destination is explicit, attributable and verifiable
Sentinel governs outbound HTTP and HTTPS Internet access for servers and managed workloads. A default-deny policy permits only approved destinations for each source; changes are assessed, approved, versioned and distributed to proxies through signed bundles.
- Default deny for servers, groups and explicit sources
- Signed, versioned policies with controlled approval
- Policy enforcement remains independent of the control plane
Governed Internet access policies
Outbound traffic passes through a dedicated control point: source, destination and reason for access become explicit policy elements.
Identified sources
Rules apply to individual hosts, groups or explicitly declared network ranges. Objects can be managed locally or synchronised read-only from an external inventory.
Normalised destinations
Exact and wildcard domains are normalised before storage. IDN handling flags mixed scripts and confusable characters before a destination enters policy.
Highly available proxies
Two or more Squid nodes enforce configuration through a virtual address. Each node knows the generation and fingerprint of its active policy, keeping cluster state verifiable.
Approved destinations
Requests matching policy are forwarded; unlisted requests are blocked by the default rule. Deterministic precedence governs both administrator-defined rules and threat-intelligence-derived blocks.
Precise, time-bound and approved rules
Sentinel treats every change as a security decision: it defines scope, calculates risk and binds each approval to the changes that will be applied.
Duration as part of policy
Rules can have start and expiry dates. Expired authorisations are not compiled; renewal is a new change, assessed against current risk and recorded in the audit trail.
Server-computed risk
Network-range breadth, wildcards, duration and domain characteristics determine the risk class. The calculation is repeated against the change content rather than trusting a value declared by the interface.
Approvals bound to the change
High-risk changes require approval from someone other than the proposer; critical changes require two approvals and fresh authentication. Any alteration invalidates previous approvals.
From change to applied configuration
A single policy representation feeds analysis, compilation and versioning. Distribution preserves the relationship between what was approved and what every node enforces.
Deterministic compilation
Explicit ordering, canonical formats and stable identifiers produce an identical configuration for the same policy. Redundancy analysis uses the same representation as the compiler.
Dedicated validation
The complete bundle undergoes structural checks and Squid syntax validation before signing. The validation service has privileges separate from those of the public API.
Signing and anti-replay protection
The Ed25519 manifest binds generation, bundle fingerprint and agent compatibility. Nodes accept only intact content signed by an authorised key and carrying a strictly increasing generation.
Atomic activation
The agent prepares the new generation in a separate path, verifies it locally and activates it through a single atomic switch. If an error occurs, the last valid configuration remains operational.
Operational continuity during a control-plane outage
The control plane governs changes but is not required to enforce an already accepted policy. Nodes continue using the last valid configuration while the API, database or Git repository are restored.
Verifiable cluster state
Node operating status, virtual-address assignment, applied generation and fingerprint determine whether the cluster can receive a new policy. Divergence blocks ordinary installation and requires cluster reconciliation.
Recovery through the standard deployment process
Restoring an earlier version produces a new signed generation without reusing a previously distributed bundle. Versions retain complete policy copies, and the current configuration is archived before recovery.
Threat intelligence, inventory and SIEM
Sentinel integrates with information sources for infrastructure, identity and risk, retaining the provenance and applied controls for each datum.
Identity and authorisation
The console uses the enterprise OIDC provider and assigns granular permissions to different operations. Reading, editing, approval, installation, recovery, node management, auditing and evidence remain separate authorisations.
Read-only inventory
Imported hosts retain the stable identity of the source system. Removals or address changes affecting objects in use are submitted for review and excluded from compilation until an operator decides.
Reputation-data provenance
Indicators are normalised, attributed to their source and given an expiry. Blocks derived from high-confidence indicators precede administrator-defined rules and remain identifiable in policy, change summaries and the interface.
Events delivered to the SIEM
Sensitive operations and distribution outcomes are structured for delivery to the external SIEM. A local queue, scheduled retries and delivery monitoring support continuity of the event stream.
Audit and verifiable evidence
The technical history connects decisions to distributed configurations and node state. Evidence distinguishes design, implementation, testing and verification activities performed in the operating environment.
Tamper-evident audit
Events are hash chained and can be verified deterministically. Proposals, approvals, installations, recovery, node changes and attempts to apply invalid bundles leave a structured trail.
Complete policy versions
Every deployment retains the restorable policy, manifest, bundle fingerprint, generation and reference to protected Git history. The change summary remains connected to the applied configuration.
Evidence levels
The control registry separates design, implementation, automated testing and verification in test or production environments. Each transition requires references consistent with the declared level.
Repeatable operational checks
A diagnostic procedure checks the database, migrations, audit chain, nodes, enforced policy, virtual address, keys, information feeds, backups, Git repository copy, integrations and security configuration, producing structured results.
Operational scope
Sentinel concentrates managed-system egress control in a dedicated service that integrates with existing infrastructure and security processes.
Servers and managed workloads
The scope covers application systems, virtual machines and workloads whose outbound HTTP/HTTPS traffic must follow source- and destination-specific authorisations.
Console, API and command-line interface
The console covers policy, change summaries, approvals, traffic, threat intelligence, nodes, versions, recovery, auditing and evidence. The API and command-line interface use the same application controls.
Dedicated and hybrid environments
The control plane and proxies are installed on dedicated infrastructure, with identity, inventory, SIEM, monitoring and key management connected according to the customer’s architecture.
Deployment model
DEC defines the scope, installs the components, integrates external systems and prepares operating procedures with the team responsible for the infrastructure.
Dedicated architecture
The control plane, database, policy repository, signing service, proxies and virtual address are sized and segmented according to source count, availability requirements and existing network boundaries.
Verifiable commissioning
Delivery covers configuration, initial object import, integrations, roles, approval procedures, backup, recovery and operational checks. Tests performed in the environment are associated with the evidence level achieved.
Egress-control assessment
DEC can review sources, destinations, HTTP/HTTPS flows, inventory, identity, approval processes, availability requirements and integrations to define a verifiable Sentinel scope.