Aegis: Run Guard Capabilities on Your Own Infrastructure

Aegis is a capability delivery runtime that lets you run Guard capabilities against assets that are not reachable from Guard's own compute — air-gapped environments, private clouds, and highly regulated networks included. You enroll an agent on your infrastructure; Guard dispatches capability tasks to it; results flow back through the standard Guard findings pipeline.

---

How Aegis Works

An Aegis agent runs as a daemon on a host you control. The agent:

1. Enrolls with Guard — acquires a short-lived, scoped identity that persists across restarts.
2. Polls for tasks — continuously checks for capability tasks assigned to it, including concurrent assignments.
3. Pulls the capability container — uses per-agent, vended pull credentials scoped to the capability image namespace to fetch a digest-pinned container from Guard's registry. No long-lived registry secrets or AWS credentials are required on the host.
4. Executes locally — runs the capability against the target endpoint on your infrastructure.
5. Reports results — sends findings back through the standard Guard ingestion path, where they appear alongside results from Guard-compute runs.

---

Key Properties

No inbound network paths required

Agents initiate all outbound connections. You do not need to open firewall rules or expose Guard credentials on your hosts.

Short-lived, scoped pull credentials

Pull credentials are vended per-agent and scoped to the capability image namespace. The host never holds long-lived registry secrets.

Digest-pinned capability containers

Each capability container is pinned to an immutable digest. What runs on your infrastructure is exactly what Guard shipped — no substitution is possible.

Write-once capabilities

Existing Guard capabilities run inside Aegis without modification. A single capability body targets both Guard compute and Aegis agent runtimes. Capabilities developed with the Guard SDK do not require separate Aegis-specific packaging.

---

Fleet Management

Guard provides fleet-level controls for Aegis agents:

---

Aegis v2 Enrollment

Operators can initiate and monitor Aegis v2 endpoint enrollment directly from the Guard UI without relying on manual or lower-level setup paths.

Enrollment flow

1. Open the enrollment UI — navigate to the Aegis section of the Guard platform and select Enroll new endpoint.
2. Provide required inputs — enter the information prompted by the form (endpoint identifier, network context, and any environment-specific parameters).
3. Follow setup instructions — the UI presents the exact steps to run on the target host to complete registration.
4. Track progress — enrollment status updates in real time. The UI reflects each stage of the handshake between the host and Guard.
5. Retry on failure — if enrollment fails at any stage, the UI surfaces the failure reason and allows you to retry safely without creating duplicate or orphaned identities.

Target specification

Aegis v2 uses a shared target contract that producers, the endpoint runtime, and the UI all interpret consistently. This contract defines:

• Supported target kinds — the set of target types that Aegis v2 endpoints accept (for example, host, repository).
• Required and optional fields — each target kind declares which fields must be present and which are optional.
• Validation rules — targets are validated against the contract before dispatch. Invalid targets are rejected early, before any task is sent to the endpoint.
• Versioning behavior — the contract is versioned so that changes to target structure are applied consistently across all components simultaneously.

You do not need to manage the target specification directly. Guard enforces it automatically when you configure targets through the UI or API.

---

Capabilities on Aegis v2 Endpoints

Internal Hunt mode with Hannibal

Internal Hunt mode is a first-class hunt type that lets security teams conduct internal network attack simulations entirely through an assigned Aegis endpoint. Hannibal's planner and model reasoning continue to run in Guard compute, while all networked internal work — scanning, exploitation, browser interaction, and spawned agent activity — executes inside the persistent endpoint sandbox.

How it works

When you launch a hunt in Internal Hunt mode:

1. Endpoint selection and confirmation — you select the Aegis endpoint through which the hunt will operate. The UI presents a clear confirmation step before any agent-initiated internal work begins.
2. Server-authored assignment — Guard assigns the endpoint to the hunt server-side. That assignment propagates automatically through targets and jobs created during the hunt. Endpoint IDs cannot be overridden by agent requests at runtime; forged or unauthorized endpoint identifiers are rejected.
3. Endpoint-aware planning — Hannibal's planner determines the correct execution path (Guard compute vs. endpoint) for each child action. Networked internal actions are dispatched to the endpoint; planner and reasoning tasks remain in Guard compute.
4. Capability fanout on endpoint — as Hannibal spawns agents, each agent inherits the endpoint assignment. Native capabilities used by internal exploit agents run fully within the endpoint sandbox.

Supported internal agent capabilities

The following capabilities are fully supported within the endpoint sandbox for internal hunts, with typed inputs and fixed entrypoints:

Observability, cancellation, and recovery

Internal hunts running through an endpoint expose the same operational controls as standard hunts:

• Durable task state — task state is persisted so that the hunt can be resumed if interrupted.
• Cancellation controls — you can cancel an in-progress internal hunt from the Guard UI; cancellation propagates to running agents on the endpoint.
• Heartbeat monitoring — Guard monitors endpoint heartbeats during an active hunt and surfaces connectivity issues in the UI.
• Startup recovery — if an endpoint run is interrupted (for example, due to a network disruption), the hunt can be resumed without manual intervention.

Guardrails

Synchronous agent commands and browser operations inside the endpoint sandbox are governed by typed contracts, resource limits, and server-owned network policy. No endpoint assignment overrides are permitted at runtime.

---

Internal DNS resolution with Resolver

The Resolver capability can be pinned to an Aegis v2 endpoint to resolve domain names via the endpoint host's locally configured DNS. This enables internal asset discovery in private network environments where Guard's standard compute path cannot reach private addresses.

When a Resolver job runs through an Aegis v2 endpoint:

• Internal name resolution — queries are forwarded through the endpoint's host-configured DNS, so names that only resolve within your private network are reachable.
• Private address results — A and AAAA records returning private unicast addresses are admitted and returned as findings. This behavior applies only to Aegis v2 execution paths; standard Guard compute paths are unaffected.

To use this capability, assign the Resolver job to an Aegis v2 endpoint that has DNS access to the internal zones you want to enumerate. No additional configuration is required on the endpoint beyond standard Aegis enrollment.

Secrets scanning with Titus

The Titus secrets scanner runs within the Aegis v2 endpoint execution environment, extending secrets detection to repositories hosted on or accessible from your endpoint. Findings are returned through the standard Guard secrets pipeline and appear alongside results from cloud-compute Titus runs.

Additional endpoint capabilities

The following capabilities are part of the Aegis v2 endpoint production runtime and are delivered through the profile and master-image architecture:

These capabilities require no additional packaging or configuration beyond enrolling the endpoint and assigning the relevant jobs.

---

When to Use Aegis

Use Aegis when your target assets are:

• Inside an air-gapped or private network unreachable from Guard's compute.
• In a highly regulated environment where external compute cannot be granted access.
• Behind network controls that prevent inbound connections from third-party infrastructure.
• Resolvable only through internal DNS servers not accessible from Guard's compute (use Aegis v2 with Resolver).
• Hosting source repositories that require secrets scanning from within the network perimeter (use Aegis v2 with Titus).
• Requiring fingerprinting, vulnerability scanning, or AD reconnaissance against internal segments (use Aegis v2 with the migrated endpoint capabilities).
• Targeted by internal network attack simulations run through Hannibal (use Aegis v2 with Internal Hunt mode).

For assets that are reachable from Guard's compute, standard Guard capability scheduling is sufficient and no agent is required.

---

Getting Started

Aegis v2 enrollment is self-service through the Guard UI. Navigate to the Aegis section of the platform and select Enroll new endpoint to begin.

To start an Internal Hunt mode hunt, enroll an Aegis v2 endpoint that has network access to your internal targets, then create a new hunt and select the enrolled endpoint when prompted. If you need assistance or are setting up Aegis for the first time, contact your Praetorian representative or open a request through the Guard platform.