Runtime Audit Telemetry
Structured, queryable event records that describe who executed what, where, when, and under which policy. Telemetry is designed to flow into existing SIEM and observability pipelines without requiring new infrastructure.
What telemetry captures
Identity & Authorization
- Actor (user, service, agent, automated process)
- Authentication method and strength
- Authority under which the action was performed
- Role, group, and permission context
Execution & Environment
- Artifact identity and version
- Target environment (cloud, region, edge, on-prem)
- Mode of execution (fixed vs adaptive)
- Runtime hosts and resource boundaries
Evidence & Traceability
- Policy decision that authorized or denied the action
- Trace IDs linking build, deploy, and runtime events
- Related telemetry for forensic reconstruction
- Attestations attached to the execution
Telemetry event schema
A minimal audit event contains the fields required for policy, forensic, and compliance queries. Additional fields can be added per deployment — but these eight are the canonical ones:
| Field | Purpose | Example |
|---|---|---|
ts |
Event timestamp (UTC, ISO 8601) | 2026-04-18T14:22:07.441Z |
actor |
Who initiated the action | user:j.patel@acme.com |
action |
What operation was attempted | execute, deploy, modify |
artifact |
What was acted on | billing-service@v4.2.1 |
policy |
Which policy evaluated the action | prod-billing-runtime-v3 |
target |
Where execution occurred | aws:us-east-1:cluster-prod-02 |
mode |
Execution mode | fixed, adaptive |
trace |
Correlation ID across related events | tr-8f2c7a91-2b14-4e8e |
Example audit events
Deploy — Policy Pass
{
"ts": "2026-04-18T14:22:07.441Z",
"actor": "user:j.patel@acme.com",
"action": "deploy",
"artifact": "billing-service@v4.2.1",
"policy": "prod-billing-deploy-v3",
"target": "aws:us-east-1:cluster-prod-02",
"mode": "fixed",
"trace": "tr-8f2c7a91-2b14-4e8e",
"result": "allowed"
}
Runtime — Policy Deny
{
"ts": "2026-04-18T14:28:33.911Z",
"actor": "service:fraud-detector",
"action": "execute",
"artifact": "customer-lookup@v2.8.0",
"policy": "pii-access-restrict-v2",
"target": "aws:us-east-1:cluster-prod-02",
"mode": "adaptive",
"trace": "tr-8f2c7a91-2b14-4e8e",
"result": "denied",
"reason": "declared-purpose violation: pii_export not authorized"
}
Where telemetry goes
SIEM Integration
Events stream into existing SIEM platforms — Splunk, Sentinel, Chronicle, Elastic — using the formats those systems already consume. No custom parsing is required for common deployments.
Observability Platforms
For teams already running OpenTelemetry, Prometheus, or similar observability stacks, telemetry can flow through the same pipelines. Runtime audit becomes part of the existing signal graph rather than a separate silo.
Evidence Bundles
For compliance workflows, selected telemetry can be packaged alongside certification artifacts (SBOMs, signed attestations, policy snapshots) for audit delivery or regulatory review — without forcing auditors to query the live SIEM.
Runtime telemetry is designed to be consumable by the tools your security team already operates — not a parallel audit platform. The value is the richer signal: actions are tied to policies, purposes, and authorities, not just to users and processes.