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:
ExportRefreshApply FiltersResetView DetailsView Prompt/Hide PromptPrevious/Next
Detail panel actions:
Export JSONGenerate Summary/ regenerateMark 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:
ExportRefresh- Topic selection in distribution map
View DetailsView 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 ChannelsSave Plan TierSave Service ProtectionSave AI Firewall / Security ShieldSave 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 analysiscontrols 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:
AddUpload(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 OperatorInvite & 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 KeyCopy KeyOpen Step-by-Step Setup GuideOpen SIEM Settings
Webhook actions (when enabled):
Add webhookSave changesCancelEditDeleteTest webhookAuto-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_failis opt-in and should only be enabled for explicit edge fast-fail requirements. - Teams using Vercel AI SDK should prefer
agentid-vercel-sdkinstead of rebuilding/guard+/ingestflow manually. - Activity metadata can include
sdk_config_fetch_ms,sdk_local_scan_ms,sdk_guard_ms, andsdk_ingest_msfor 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 DetailsSave Business ContextBump VersionEdit 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_artifactshas an active row for the system.ai_systems.policy_pack_version > 0.- New runtime logs include:
policy_pack_fallback=falsepolicy_pack_versionpopulated
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
CompleteandSecurity Alertrows 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 alongsideprocessing_time_ms, not as replacements for it. - When
AI analysisis enabled, the log detail sheet can later show Tier-2 forensic fields fromevaluation_metadata.forensic_audit, including:- intent
- threat analysis
- clean summary
- sophistication
- requested/provider model