Designed to check security controls where systems run

The problem it is for

A control can be correct on paper and missing on the machine. Today, people check periodically and collect evidence for the audit rather than as systems run. Meanwhile administrators and automation change systems daily, and nothing checks a risky command against policy before it runs.

Guardian Angel is Guardian’s endpoint component. It will evaluate approved controls beside the systems they govern, return evidence, flag deviations from policy and guard what operators run.

From a policy to a specific machine

Angel works on controls scoped to one resource, described in three tiers:

Tier	What it describes
L1: Identity and mission	What the resource is, who owns it, its purpose, classification and risk
L2: Architecture and relationships	Components, identities, dependencies, management plane and data flows
L3: Technical detail	Platform and benchmark versions, hardening, security features and constraints

From that description, Guardian resolves the policy catalogue into a control pack for the resource: which controls apply, how to configure each and how to verify it.

Planned capabilities

How Angel works

1. 1

   Operator or automation

   A person or automated task issues commands on an endpoint or server.

2. 2

   Protected shell

   Angel intercepts shell and PowerShell activity and applies guardrails before execution.

3. 3

   Policy and compliance engine

   Angel evaluates each command against the applicable controls and its context, then allows, warns or blocks.

4. 4

   Endpoint execution and telemetry

   Approved actions run while Angel observes process, file, command and configuration changes.

5. 5

   Monitoring and response

   Angel tracks deviations and drift and hands them to people to remediate and review.

Angel will also keep three records: a searchable log of commands, policy decisions and endpoint events; a map of endpoint activity to controls, with evidence of enforcement; and a history of drift, unexpected changes and repeated violations.

Connected and standalone

Connected: Guardian Nexus supplies approved, scoped controls. Angel returns findings and evidence, and Nexus links them to the source clause for deviation review.

Standalone: authorised staff supply a validated local control bundle. Angel assesses and reports within the same boundaries, through an approved export. Without Nexus, findings may not trace back to a source clause.

Where Angel starts

Angel starts with endpoints and servers: their baselines are concrete, their audit requirements are clear and checking them by hand is expensive. Cloud, privileged access and networks come next. Databases, firewalls and operational technology may need dedicated adapters.

Boundaries still to be established

Angel will run close to sensitive systems. We will settle these before any release:

• Which checks Angel may run, and how each is authorised, signed and versioned so it cannot become arbitrary command execution.
• Which privileges checks run with, how Angel handles secrets and where the isolation boundary sits. “Protected execution” is not a claim of a sandbox, enclave or hardware isolation.
• Which data leaves the machine and which stays local.
• How Angel behaves offline, with an out-of-date bundle, or when a check fails or cannot decide.
• How updates and communication with Nexus stay intact.

Angel does not fix things automatically. People approve, and the system logs, every corrective action.