IR-4: Outpost Compromise

Severity: CRITICAL

Scope: Hybrid Outpost on customer-managed infrastructure has been accessed without authorization, is exhibiting tampered policy bundles, or is communicating with the control plane under suspicious circumstances.

IC role required for: outpost disconnect, certificate revocation, audit freeze.

Related documentation: Certificate Management — Outpost Security Hardening — Kill Switch Operations — Audit Log Verification — Credential Management

---

1. Detection

An outpost compromise may be detected through any of the following signals. Check all channels before declaring severity level.

Signal	Source	Details
Health check failures for an outpost that was previously healthy	/readyz response from outpost host	Repeated 503 or connection refused after previously stable operation
Outpost presenting an expired or invalid mTLS client certificate	Control plane TLS handshake logs	Cert CN mismatch, chain validation failure, or cert serial not matching the registered outpost record
Unauthorized access to the outpost host	Customer security team report	SSH from unknown IP, unexpected process running, unauthorized filesystem access
Unexpected or high-frequency policy sync requests from outpost	Control plane API logs	Outpost sync loop firing outside its configured interval or in a pattern inconsistent with normal cadence
Anomalous outbound traffic from the outpost IP	Customer network monitoring	Unusual destinations, large data volumes, or traffic on unexpected ports
Signed policy bundle fails signature verification on the outpost	Outpost startup or policy reload logs	policy bundle signature invalid in outpost log output
DLP pipeline outputs inconsistent with policy at the time of the traffic	Audit log review	Requests that should have been blocked passed through, or blocked content that should not have been

Do not wait for multiple signals. A single confirmed indicator (e.g., unauthorized SSH access to the outpost host) is sufficient to declare CRITICAL and activate IC.

---

2. Severity classification

Classification	Criteria
CRITICAL (default for this playbook)	Any confirmed unauthorized access to the outpost host, or mTLS cert anomaly, or tampered policy bundle
HIGH	Unexplained health check failures or anomalous traffic — outpost behavior suspicious but compromise not yet confirmed
MEDIUM	Outpost offline but no evidence of compromise — treat as infrastructure failure, not security incident

Escalate to CRITICAL and activate IC immediately if customer confirms unauthorized host access or if policy bundles are suspected tampered.

---

3. Immediate actions (first 15 minutes)

Work through this checklist in order. The outpost can continue operating autonomously on its last-synced policy bundle after disconnect — containment does not cause a customer service outage unless the outpost itself is taken offline.

Step	Action	Done
1	Declare the incident in Staff UI or via Staff API
2	Disconnect the outpost from the control plane
3	Freeze the audit log
4	Note the outpost CN and incident ID for cross-referencing
5	Alert the customer security team to isolate the outpost host from their internal network

Step 1 — Declare the incident:

curl -X POST https://api.arbitex.ai/api/staff/incident/declare \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "IR-4: Outpost compromise — [customer_name] outpost [outpost_id]",
    "severity": "critical",
    "playbook": "ir-4-outpost-compromise"
  }'

Note the incident_id from the response — all subsequent actions must reference it.

Step 2 — Disconnect the outpost from the control plane:

curl -X POST https://api.arbitex.ai/api/staff/emergency/outpost/disconnect \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "outpost_id": "<outpost_uuid>",
    "incident_id": "<incident_id>",
    "reason": "Outpost compromise — IR-4 activated"
  }'

After this call, the control plane will:

• Stop accepting policy sync requests from the outpost’s mTLS CN
• Stop pushing policy bundle updates to the outpost
• Stop processing credential sync events from the outpost
• Record the disconnection in the audit log with the incident ID

The outpost continues to function locally on its last-synced policy bundle. It will not receive updated policies or credentials until re-registered.

Step 3 — Freeze the audit log:

curl -X POST https://api.arbitex.ai/api/staff/emergency/audit/freeze \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "incident_id": "<incident_id>",
    "reason": "Preserving audit trail for IR-4 outpost compromise investigation"
  }'

A frozen audit log remains readable but write operations are suspended. Freeze as early as possible to prevent any evidence being overwritten.

---

4. Investigation

Audit trail review

Pull all audit events associated with the outpost’s mTLS CN to identify unauthorized API usage:

# Export audit events from the outpost's CN for the past 30 days
curl -X POST https://api.arbitex.ai/api/v1/admin/audit/export \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "source_cn": "<outpost_mtls_cn>",
    "start_date": "<30_days_ago>",
    "end_date": "<today>",
    "format": "jsonl"
  }'

Review the export for:

• Requests originating from the outpost CN at unexpected times
• Policy sync requests outside the configured interval
• Any admin API calls made using the outpost identity (the outpost CN should only appear in proxy/sync operations)
• DLP verdicts inconsistent with the active policy bundle at the time of the event

HMAC chain verification

Verify the audit chain has not been tampered with since the outpost was last seen healthy:

curl -X POST https://api.arbitex.ai/api/v1/admin/audit/verify \
  -H "Authorization: Bearer $ADMIN_TOKEN"

A valid: true response with zero errors confirms the audit chain is intact for that window. If valid: false, record the first broken entry as evidence — the HMAC chain uses HMAC-SHA256 with a GENESIS sentinel of 64 zero hex characters for the first entry. Any break indicates a deletion or modification.

Policy bundle integrity check

On the outpost host (coordinated with the customer), verify the bundle signature:

# On the outpost host — check policy bundle signature
arbitex-outpost policy verify --bundle /var/lib/arbitex/policy-bundle.json

# Expected output on a healthy outpost:
# Policy bundle signature: VALID
# Signed by: arbitex-policy-signer (key ID: <key_uuid>)
# Bundle version: <version>
# Verified at: <timestamp>

If the signature check fails, the bundle has been tampered with. Document the bundle hash and the signing key ID from the failed verification output.

Data exposure assessment

Determine whether the outpost was used to exfiltrate data through the DLP pipeline:

1. Review all proxy requests forwarded by this outpost during the suspected compromise window — look for requests where DLP scan results were overridden or where the outpost bypassed the 5-tier DLP pipeline.
2. Check for unusually large response payloads from model providers passing back through the outpost.
3. Review any API calls made to credential sync endpoints using the outpost’s identity — check whether the outpost received credentials it should not have had access to.

---

5. Containment

Control	Action	Endpoint
Disconnect outpost	Stop control plane communication	POST /api/staff/emergency/outpost/disconnect
Revoke outpost mTLS client certificate	Prevent cert re-use if attacker has the private key	Certificate revocation via Certificate Management
Isolate outpost host	Customer action — remove from network	Coordinate with customer security team
Freeze audit log	Preserve evidence	POST /api/staff/emergency/audit/freeze
Review all credentials synced to outpost	Identify any credentials that may now be compromised	GET /api/v1/admin/credentials?outpost_id=<uuid>

If any credentials were synced to the compromised outpost, treat them as compromised and rotate or revoke immediately:

# Revoke a specific credential
curl -X DELETE https://api.arbitex.ai/api/v1/admin/credentials/<credential_id> \
  -H "Authorization: Bearer $ADMIN_TOKEN"

# Rotate a credential (preserves service continuity with grace period)
curl -X POST https://api.arbitex.ai/api/v1/admin/credentials/<credential_id>/rotate \
  -H "Authorization: Bearer $ADMIN_TOKEN"

If the scope of compromised credentials is large or unknown, use the bulk emergency revocation endpoint. This is a destructive action — confirm scope with the customer before executing:

curl -X POST https://api.arbitex.ai/api/staff/emergency/credentials/revoke-all \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "incident_id": "<incident_id>",
    "scope": "outpost",
    "outpost_id": "<outpost_uuid>",
    "reason": "Outpost compromise — IR-4"
  }'

---

6. Recovery

Recovery requires coordinated action between the Arbitex incident team and the customer’s security team. Do not reconnect the outpost until all steps below are complete and verified.

Step	Responsible	Verification
Customer rebuilds outpost from clean image	Customer	Fresh OS + fresh Arbitex outpost package, no data carried from compromised host
Customer verifies outpost host network isolation during rebuild	Customer	No network access to compromised host during rebuild
Re-register outpost with control plane to obtain new mTLS client certificate	Customer + Arbitex ops	New cert CN recorded in outpost registry, old cert CN in revocation list
Verify new policy bundle received and signature valid on fresh outpost	Customer	arbitex-outpost policy verify returns VALID
Verify all rotated credentials have been updated in customer configuration	Customer	No requests failing with 401 unauthorized from outpost after reconnect
Restore audit log from freeze	Arbitex ops	Only after evidence export is confirmed complete
Close incident	IC	POST /api/staff/incident/<id>/close

Restore audit log from freeze:

# Unfreeze after evidence is secured
curl -X POST https://api.arbitex.ai/api/staff/incident/<incident_id>/close \
  -H "Authorization: Bearer $STAFF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"resolution": "Outpost rebuilt and re-registered. Evidence preserved. Credentials rotated."}'

---

7. Communication

Internal notification (immediate — within 15 minutes of detection)

Send to: Engineering lead, Security lead, Customer Success lead, Legal.

Subject: [IR-4 ACTIVE] Outpost compromise — [customer_name]

Incident ID: <incident_id>
Declared: <timestamp>
Severity: CRITICAL

Summary: A Hybrid Outpost associated with [customer_name] (outpost ID: <uuid>)
shows evidence of unauthorized access. The outpost has been disconnected from
the control plane as of <timestamp>.

Current status: Investigating scope of access. Audit log frozen.

Customer status: Customer security team notified at <timestamp>.

Next update: <30 minutes from now>
IC: <name>

Customer notification (within 30 minutes of declaration)

Send to: Customer’s designated security contact.

Subject: Security notification — Arbitex Hybrid Outpost incident

We have detected a potential security incident affecting the Hybrid Outpost
deployed in your environment (outpost ID: <outpost_id>).

As a precautionary measure, we have disconnected the outpost from the Arbitex
control plane at <timestamp UTC>. Your outpost will continue to process traffic
using its last-synced policies but will not receive policy updates or credential
syncs during the investigation.

Immediate action requested from your team:
1. Isolate the outpost host from your internal network as soon as possible
2. Do not restart or shut down the outpost host until our forensic investigation
   is complete — we will coordinate timing with you
3. Provide us with any access logs or network monitoring data from the outpost
   host covering the past 30 days

We will provide a further update within <2 hours>.

Arbitex Security Team
incident-<incident_id>@arbitex.ai

Customer — scope confirmed

If investigation confirms data was processed through a tampered DLP pipeline:

Subject: [UPDATE] Arbitex security incident — potential data exposure

This is a follow-up to our earlier notification regarding incident <incident_id>.

Our investigation has identified that traffic processed through the compromised
outpost between <start_time> and <end_time> may have passed through a tampered
DLP pipeline. We are preparing a detailed timeline of affected requests.

We are working with your security team to:
- Identify the specific requests affected
- Determine whether any sensitive content was exposed
- Assess whether any downstream notification obligations apply

Next update: <4 hours from this message>

---

8. Post-incident

Task	Owner	Timing
Export and archive full audit trail for the incident window	Arbitex Security	Before audit unfreeze
Document the attack vector — how was the outpost host accessed?	Joint (Arbitex + Customer)	Within 72 hours
Verify revocation list includes old outpost mTLS CN	Arbitex ops	Before incident close
Update outpost hardening documentation if new attack vector identified	Docs team	Within 1 sprint
Root cause analysis report to affected customer	Arbitex Security	Within 5 business days
Review all other customer outposts for similar indicators	Arbitex Security	Within 24 hours of containment

For all post-incident evidence exports, use the audit export API before unfreezing:

curl -X POST https://api.arbitex.ai/api/v1/admin/audit/export \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "start_date": "<investigation_window_start_date>",
    "end_date": "<investigation_window_end_date>",
    "format": "jsonl",
    "include_hmac": true
  }'

Store the export with the HMAC fields included ("include_hmac": true) so the chain integrity can be verified independently by the customer or a third-party auditor.