Skip to main content

5. Single-System Control Plane: Operations

Functional Documentation

The Single-System Control Plane is the runtime cockpit for one AI system. It is where operators monitor activity, tune enforcement behavior, manage integrations, and control operational access.

1) System Overview

Purpose: At-a-glance health view of one system (runtime state, traffic/risk snapshots, top-level KPIs).

What you can do:

  • Navigate directly into operational modules from one screen.

Main actions:

  • Open Activity
  • Open Prompts
  • Open Guardrails
  • Open Integration
  • Open Access
  • Open Settings

Notes:

  • Some actions are role-gated (for example Access and sensitive integration actions are admin-only).

2) Activity (Logs)

Purpose: Full event timeline for the system, including guard and complete lifecycle records.

What you can do:

  • Investigate incidents.
  • Validate guard behavior.
  • Inspect prompt/output evidence.
  • Review Tier-2 forensic audit fields such as intent, threat analysis, clean summary, detected signals, and requested/provider model.

Main actions:

  • Export
  • Refresh
  • Apply Filters
  • Reset
  • View Details
  • View Prompt / Hide Prompt
  • Previous / Next

Detail panel actions:

  • Export JSON
  • Generate Summary / regenerate
  • Mark as False Positive (permission-based)

3) Prompt Explorer

Purpose: Prompt/output analysis workspace for prompt-level observability and patterns.

What you can do:

  • Explore prompt history.
  • Inspect topic clusters.
  • Pivot from topic insights to raw events.

Main actions:

  • Export
  • Refresh
  • Topic selection in distribution map
  • View Details
  • View Prompt

Notes:

  • Reuses timeline and filter mechanics from Activity but is optimized for prompt-intelligence workflows.

4) Guardrails

Purpose: Runtime security posture and enforcement controls for the system.

What you can do:

  • Configure allow/block behavior.
  • Configure strict mode.
  • Configure AI audit behavior.
  • Configure protection modules.

Main actions:

  • Save Notification Channels
  • Save Plan Tier
  • Save Service Protection
  • Save AI Firewall / Security Shield
  • Save Circuit Breaker

Typical toggles:

  • strict security mode
  • shadow mode
  • AI analysis
  • block prompt injection
  • block DB access
  • block code execution
  • block toxicity
  • block PII leakage
  • encrypted payload handling

Notes:

  • Changes are explicit-save. Unsaved changes are not enforced.
  • AI analysis controls the asynchronous Tier-2 forensic audit. It does not replace the synchronous guard verdict; it enriches the stored event for auditor review.

5) Blacklist & Policies

Purpose: Deterministic policy layer for blocked terms and rule-based enforcement.

What you can do:

  • Maintain blocklists.
  • Bulk import policy terms.

Main actions:

  • Add
  • Upload (CSV import)
  • Delete

Notes:

  • This is a pre-execution deterministic layer. Edit rights are role-restricted.

6) Access

Purpose: Role-based control over who can operate this system.

What you can do:

  • Assign internal operators.
  • Invite and assign customer collaborators by allowed roles.

Main actions:

  • Assign Operator
  • Invite & Assign
  • Revoke/remove assignment

Notes:

  • Admin permissions are required for management actions.

7) Integration (SDK)

Purpose: Connect runtime traffic to AgentID through SDK keys, setup guidance, and outbound hooks.

What you can do:

  • Generate and manage API keys.
  • Configure SIEM/webhook delivery.
  • Copy SDK quickstart assets.

Main actions:

  • Generate Key
  • Copy Key
  • Open Step-by-Step Setup Guide
  • Open SIEM Settings

Webhook actions (when enabled):

  • Add webhook
  • Save changes
  • Cancel
  • Edit
  • Delete
  • Test webhook
  • Auto-generate secret

Notes:

  • Some integration surfaces are hidden or read-only in customer-managed contexts.
  • Official SDKs are backend-first by default. clientFastFail / client_fast_fail is opt-in and should only be enabled for explicit edge fast-fail requirements.
  • Teams using Vercel AI SDK should prefer agentid-vercel-sdk instead of rebuilding /guard + /ingest flow manually.
  • Activity metadata can include sdk_config_fetch_ms, sdk_local_scan_ms, sdk_guard_ms, and sdk_ingest_ms for wrapper-level latency diagnostics.

8) Settings

Purpose: Operational metadata and system configuration management.

What you can do:

  • Update system details.
  • Update business context.
  • Manage versioning metadata.

Main actions:

  • Save System Details
  • Save Business Context
  • Bump Version
  • Edit in Guardrails / Open Guardrails

Notes:

  • Runtime security controls are managed in Guardrails; Settings handles metadata and links into enforcement configuration.

9) Policy Pack Runtime Verification

Purpose: Confirm that precompiled pattern artifacts are active and runtime is not on fallback detection.

What to verify:

  • policy_pack_artifacts has an active row for the system.
  • ai_systems.policy_pack_version > 0.
  • New runtime logs include:
    • policy_pack_fallback=false
    • policy_pack_version populated

Operational runbook commands (repo/local):

node scripts/qa/bootstrap-policy-pack-and-verify.mjs --base-url=http://127.0.0.1:3000/api/v1 --system-id=<SYSTEM_UUID>
npm run bench:policy-pack-hotpath

Expected benchmark target:

  • hot-path p95 under 30 ms for 10k-rule synthetic pack (normalization + prefilter + regex eval).

10) Activity Log Interpretation

Purpose: Avoid false alarms while validating runtime behavior.

Interpretation rules:

  • Latency (ms) in Activity corresponds to synchronous request processing (processing_time_ms).
  • Async forensic audit duration is separate (ai_audit_duration_ms) and can be significantly higher.
  • First request after warm-up boundary can be higher latency than subsequent requests.
  • Mixed Complete and Security Alert rows are normal when some tests call guard-only paths.
  • SDK wrapper timings appear separately in metadata (sdk_config_fetch_ms, sdk_local_scan_ms, sdk_guard_ms, sdk_ingest_ms) and should be interpreted alongside processing_time_ms, not as replacements for it.
  • When AI analysis is enabled, the log detail sheet can later show Tier-2 forensic fields from evaluation_metadata.forensic_audit, including:
    • intent
    • threat analysis
    • clean summary
    • sophistication
    • requested/provider model