Glossary

Where this alert sits in the operator-response workflow. Pending → Acknowledged → Resolved is the canonical lifecycle; the filter pills above the table let you scope the view to one stage at a time. Operators use Pending as their daily worklist; auditors check that every critical or high alert reached Resolved within the SLA window and that the resolution reason is documented.

What the agent actually did — the tool called and its arguments. Tool input is rendered verbatim and can include sensitive payloads. Where customer PII tokenisation is configured, tokens here are reversible only by the operator's browser-resident key; the server never sees the cleartext.

The AGT action verb and the resource it targeted — e.g. `read → customers/123` or `delete → tickets/4567`. AGT extracts both from the SDK call site at audit time. Maps cleanly to standard access-control vocabulary (action + resource), so Shield policies and external auditors read it without translation. Either half can be missing when the SDK omits it.

A 0-to-1 measure of how varied the agent's action choices are over its recent activity window. High entropy (≥ 0.7) means the agent is healthily exploring its tool space — using different tools, taking different paths through workflows, varying its arguments. Low entropy (< 0.2) means the agent has narrowed to a small repeat-loop of the same calls — this is the classic "stuck in a loop" failure mode, often a precursor to a runaway-cost incident or a quality-collapse degradation. Mid-range (0.2-0.7) is normal-but-watch. The gauge is computed by AGT's ActionEntropyScorer using Shannon entropy over the agent's action stream; it's intentionally light on assumptions so it works across very different agent designs.

Count of distinct agents that emitted at least one audit event during the current window. Sliding scope: drops idle agents and lights up new ones the moment they fire their first event. Operators read it as the live activity baseline against which sudden growth (rogue spin-up) or collapse (outage) shows up; auditors compare it to expected fleet size for the period under review.

The unique identifier of the AI agent that emitted the event — typically the agent's decentralised identifier (DID) from the AGT runtime. Click an agent to deep-link into its detail page with this filter applied. Auditors verify that every event is attributable to a known agent; unknown or system-injected agent IDs are filtered from the user view but remain visible in raw export.

Per-agent monthly spend cap configured against AGT's `agent_sre.cost.AgentBudget`. The table shows each agent's budget in USD, spend to date, and utilisation. Budgets are advisory by default — crossing one triggers a Cost guard alert rather than blocking execution — but operators can wire enforcement actions (pause / step-up approval) in Shield. The table hides until at least one agent budget is configured at the org level.

The internal Wytness GUID for the agent that emitted the event, distinct from the human-readable `agent_id` shown alongside. The GUID is the registry primary key — copy it to deep-link reverse lookups, attach to support tickets, or paste into the Events search to pivot the table. Most operators won't need to read this, but auditors sometimes ask for the GUID to cross-reference with the agent identity registry.

Count of distinct agents that have invoked this tool within the 30-day window. Two agents calling the same tool show as `2` even if one called it once and the other called it 10,000 times — this is a coverage signal, not a volume signal. Operators use it to spot tools concentrated to a single agent (good policy candidates) versus tools used by many agents (where a single policy change has broad blast radius); auditors flag tools with unexpectedly high agent diversity as candidates for permission tightening.

The decentralised identifier (DID) the AGT runtime assigned to this agent — a self-describing URN that resolves to the agent's Ed25519 public key in the AGT identity registry. The DID is the "who ran this" anchor: every AGT-signed event is verifiable against the public key registered for the DID. Auditors require a DID on every production event; legacy rows without one pre-date the v2 ingest path.

The "chain wasn't altered" verdict — re-walks AGT's tamper-evidence structure (Merkle tree in Python AGT, flat link chain in TypeScript AGT) and confirms this event's stored Entry hash matches a fresh recompute and its Previous hash matches the prior event. Auditors require all three Crypto layer verdicts green for evidence acceptance.

The "who ran this" verdict — confirms AGT's Ed25519 identity signature over the event matches the public key registered for the agent's DID. AGT-side identity, distinct from the Wytness envelope. Carries through IATP delegation: when an agent is acting on another agent's behalf, the delegation chain is verified at this layer.

The Microsoft AGT (Agent Governance Toolkit) runtime version that produced the underlying audit entry on the customer side. AGT is the open-source signing, hash-chain, and identity layer; Wytness wraps it. Newer AGT versions add fields like protocol facets and expanded audit metadata. Operators investigating field-availability gaps cross-reference this against the AGT release notes.

The AGT 4.0 runtime's view of where this agent sits in its operational lifecycle, distinct from your governance Approval status. Approval is a Wytness/governance signal you set in Registry; AGT state is what AGT itself reports about the agent's runtime registration. Both can be useful — for instance, an agent your governance has Approved but AGT has marked Deprecated needs a sunset plan.

Number of anomaly alerts raised by the seven-rule detection engine during the current window. Each alert pairs an agent with a flagged behaviour — error-rate spike, off-hours activity, capability deviation, or similar. Click through to Anomalies for the full triage view. A zero reading is healthy; a non-zero reading is not necessarily a regression but it deserves a look.

A normalised view of anomaly volume per agent, expressed as anomalies per 1,000 events within the active window. Normalising for traffic stops the loudest agents from also being the most-alarming agents simply because they emit more events — a quiet agent with a high per-1k rate is more likely to be the real concern. Operators sort the bar chart top-down for triage; auditors quote per-1k rates in fleet-health summaries because they're comparable across agents and across organisations.

The Bearer credential the Wytness wrapper sends on every `/ingest` request to authenticate to your organisation. Created on this page, passed to the wrapper as the `WYTNESS_API_KEY` environment variable. Wytness stores only a SHA-256 hash of the key — the plaintext is shown exactly once at creation time, so capture it then or revoke and recreate. Auditors check the rotation cadence in Key History and confirm that revoked keys cannot resume ingest. Compromise is recoverable: revoke the key and any wrapper using it stops authenticating immediately.

Where the agent sits in your governance workflow. Operators move agents from pending → approved after classifying their EU AI Act tier on Registry. Auditors verify that every agent in the production environment has reached `approved`, and that deprecated agents have a documented sunset plan.

The Azure Blob container that holds your authoritative JSONL audit archive. Wytness creates one blob per ingest batch under a date-partitioned key, signed-and-sealed end-to-end. WORM and retention policies apply here. Container name is fixed at `wytness-archive` — the storage account URL you supply scopes which account it lives in, but the container name is not user-configurable so the chain-verifier can find it without per-customer routing. Distinct from the poison container, which is where envelope-verify failures and integrity-flagged events are diverted so they do not contaminate the trusted archive.

Which capture path attested to this event, and how strongly. Signed-at-action events carry a signature made at the moment the agent acted; collected events were captured afterwards from the customer's own logging store (Foundry traces, Copilot Studio telemetry) and signed inside the customer's boundary at pickup. The tiers never mix silently: a session containing both renders as Mixed, and this filter narrows the Events list to one tier for scoped review.

How many times Wytness has POSTed this event to the connector so far, counting the initial dispatch and every retry. Rows whose attempt count is above one without yet reaching Delivered indicate transient downstream failures the retry scheduler is actively working around. Operators investigate rows whose count is at or near the retry cap; auditors verify that the cap is consistent with the downstream system's documented availability.

How this event's attribution was established. Direct events were attributed at the moment of capture; collected events inherit their attribution from the source log's metadata (agent name, conversation id) at pickup; unattributed marks events stranded after a chain break. Auditors use this to weight evidence — a collected event proves what the log said, while a direct signed event proves what the agent did at the time it acted.

The nine numbered sections rendered inside every generated pack, in the order an auditor reads them. Operators use the Table of Contents to jump to a section while reviewing a pack on screen; auditors mark each section against their evidence-collection checklist. The set is fixed — every pack contains every section, even if a section renders empty for the chosen period (the pack itself records the empty state so the absence is auditable).

What the agent was permitted to do when it performed this action. Lists the scope permissions in effect at the time of the event, as reported by the SDK. Auditors verify that the action was within the agent's authorised scope; an empty permissions list points at SDK or configuration drift, not a policy block.

Mean tool-invocation latency across every event in the current window, regardless of outcome status. Timeouts are included in the calculation and pull the average up — a useful "is everything getting slower?" signal but not a clean success-path latency. Rendered in milliseconds for sub-second values and seconds with two decimal places for longer ones. For percentile latency, drill into a specific agent or tool.

The AWS object-storage backend for private storage archive, paired with S3 Object Lock as the WORM-equivalent immutability primitive. Not yet available — the V2-S3-ADAPTER roadmap item tracks the work, which spans an S3-aware Boto3 writer, an IAM-role / access-key authentication path, and an Object Lock retention policy probe that mirrors what the Azure Blob immutability check already does. Until S3 ships, Azure Blob is the only supported archive destination.

The Azure storage account that holds your long-term JSONL archive of audit events. Wytness writes one blob per ingest batch into a `wytness-archive` container under the account URL you supply, using a service principal (Azure AD app registration) granted the Storage Blob Data Contributor role. Hot queries hit your ClickHouse; the blob archive is the durable, compaction-resistant copy that Evidence Packs and the chain-replay verifier read from. The setup wizard asks for the storage account URL, the Azure directory (tenant) ID, and the service principal's client ID + secret so Wytness can authenticate as that principal at write time. AWS S3 is on the roadmap but not yet supported — Azure Blob is the only provider option at launch.

The UTC-anchored calendar month that scopes every counter on this page — events, agents, and overage all reset at 00:00 UTC on the first of the next month. A Sydney customer ingesting at 09:00 AEST on 1 May (= 23:00 UTC 30 Apr) still sees that event in the prior month's bar until UTC midnight rolls; the cycle is deliberately TZ-stable so invoices reconcile against the same boundary worldwide. Auditors map the cycle to the customer's fiscal reporting period when sizing evidence packs.

The cadence on which the subscription is billed. Monthly is the default and carries no commitment; yearly prepays the year for two months free. Switching from monthly to yearly (or back) on the current plan keeps the tier the same and re-issues the price difference as a prorated credit. Enterprise is annual by default; no monthly option.

`status=blocked` means Shield's policy engine intercepted the call **before** execution. The tool never ran. This is distinct from `failure` (tool ran and errored) — `blocked` is a deliberate policy decision, not a runtime fault. Renders as an amber badge with the `Blocked` label; the event row gets an amber tint (`var(--wyt-warning-bg)`) so operators see the policy-intercepted action at a glance. The Tools page's "errors" count does NOT include blocked events — blocked is its own outcome, separately surfaced. Wytness still records the attempt as evidence (the agent tried to call a restricted tool); the chain is intact across the blocked event.

The neighbouring events around a chain break — the predecessor whose hash should have matched, the broken event itself, and the next event after the discontinuity. Operators click "Inspect" on a break card to surface this sequence so they can see exactly which link failed and which neighbours are intact. Auditors use the captured context to distinguish a benign SDK restart (a `wytness.sdk_init` row appearing at the break point) from a tampering signal.

Audit data lands in storage YOU own, not Wytness's. Once you activate private storage, every new event your wrapper signs is written into your Azure ClickHouse instance for hot queries and archived as JSONL into your Azure Blob Storage account for long-term retention. Wytness never holds a copy. The Wytness app continues to read from your endpoints over the credentials you supplied, so the dashboard, exports, and Evidence Packs all work unchanged — but if you cut off our access, we lose the ability to read your trail, and your archive is yours alone to keep. BYOS is a Business-tier feature. The defensible property for auditors: there is no point where Wytness control plane and your data plane co-exist on Wytness hardware.

Input tokens the vendor served from its prompt cache instead of processing fresh, billed at a steep discount. A high cache-read share against a stable system prompt is the sign that caching is working; a low one on repetitive workloads usually means the cached prefix is being invalidated by something that changes every call. This is counted apart from input tokens so the two rates are never conflated in the cost estimate.

Input tokens the vendor charged a premium to place into its prompt cache. Cache writes cost more than ordinary input and pay for themselves only if the same prefix is read back enough times, so an operator seeing writes far outnumber reads is paying for a cache nobody is hitting. It is tracked separately for the same reason as cache reads: its rate differs, and blending it would hide the trade.

How many model invocations your agents made against this model in the current billing cycle. Only calls your SDK captured are counted, so a model your agents use without instrumentation will not appear at all — an absent row means no capture, not no usage. An auditor pairs the call count with the agent column to see how model use is distributed across the fleet.

What happens to event ingest once the running cycle count crosses the plan's included quota. Wytness defaults to metered overage on paid tiers so the audit trail never goes dark — losing events at the cap creates the compliance gap an audit trail is supposed to prevent. Operators watch the projection card to decide between paying overage and upgrading; auditors confirm no events were dropped during the period under review.

AGT 4.0's CapabilityProfileDeviation rule fires when an agent uses a capability that wasn't declared in its registered capability profile — for example, an agent registered as `read_only` that performs a write or delete. Source: `agent_sre.anomaly.CapabilityProfileDeviation` (AGT 4.0). The panel diffs the registered (expected) and observed capability sets: capabilities present in observed but missing from expected are flagged as escalations in red; capabilities present in expected but unused in this run are shown as a side-note. Operators verify the agent's registered profile in Registry is still accurate, then kill-switch the agent if the unregistered capability was a privilege escalation. Auditors verify that every capability the agent exercised was either declared or recorded as a deviation. Backend extract is pending — until then, when the rule fires without sets the panel surfaces an honest placeholder so the rule firing is still visible.

Narrow the table to events that sit at a broken chain link. A break means the event's stored predecessor-hash does not match the actual predecessor's hash — the chain of custody is compromised at this point. The complete cross-agent break list lives on the Verify page; this filter is for triage in context.

Line chart of the percentage of events that successfully verified their cryptographic chain link, bucketed by hour or day to match the Event Volume chart above. Healthy traces sit flat at 100%; a dip — drawn as a red dot — marks a bucket where at least one event broke its chain. Operators use it to pinpoint when a tamper signal began; auditors expect a continuous green line across the entire period under review.

The position of this event within its agent's hash chain — a monotonically increasing counter per agent. Used together with the previous-hash to detect chain breaks and reordering. Auditors confirm the index is contiguous from the agent's first event onward; gaps indicate dropped or unrecorded events.

How densely the chain inspector samples the agent's event stream for rendering — every event, 1 in 10, 1 in 100, or auto-picked by the server. Lower sample rates keep the SVG snappy on long chains; higher rates surface every potential break for forensic review. Operators typically leave this on Auto and switch to All when investigating a specific break window.

Percentage of audit events whose cryptographic chain link to the predecessor verifies successfully, plus a count of unresolved breaks. A 100% reading with zero unresolved breaks is the regulator-ready posture; anything less means at least one event's previous-hash failed to match its predecessor's hash. Sticky across the Window selector — a break is a break regardless of time range. Click through to Verify to investigate. Auditors halt evidence acceptance the moment this drops below 100%.

Whether this event sits in an intact cryptographic chain of custody. Each event embeds the hash of its predecessor; a `break` means the predecessor was altered, deleted, or never received — the immutable audit guarantee is compromised. `unattributed` means the chain math passes but the AGT identity layer is missing (no DID), so we can't tie the event to a signed agent identity. Auditors require `verified` across the entire period under review; any `break` event halts evidence acceptance until investigated. Locked by `docs/facts/event-status-semantics.md`.

The Trace tab's List layout: every event in the session top-to-bottom with a chain-link verdict between cards, computed server-side from the actual hash material — linked, chain start, break, or no-chain for collected-tier capture. Intact links show the hash prefix that was compared; at a broken link a prominent banner interrupts the flow showing the expected vs stored hash and the time gap. Only the breaking event itself is accused — events after it that link cleanly stay verified, and a redacted predecessor (GDPR Art. 17) is accepted, never reported as tampering. Operators use the strip to pinpoint exactly where tampering or data loss occurred; auditors photograph this view as evidence in incident reports.

An event that carries no hash-chain link because nothing instrumented the agent at the moment it acted — every collected event is chainless by design, since the collector reads a log after the fact. It still carries a signature and tokenized payload made inside the customer's boundary, so non-repudiation and privacy hold; what it cannot offer is the sequence proof that a chained event gets. Verification surfaces treat an absent chain as absent rather than broken, so an auditor should read a chainless event as a weaker claim, never as evidence of tampering.

The data-classification tag the SDK applied to the inputs payload — typically `public`, `internal`, `confidential`, `restricted`, or `pii`. Drives downstream Shield policies and PII tokenisation. Auditors verify the classification matches the documented sensitivity of the tool's data domain; an unexpected `restricted` or `pii` tag on a tool meant for low-sensitivity work is worth investigating.

The operator's note recorded against a risk or approval change in the Classify dialog. Required whenever risk or approval moves; recorded against the signed audit-trail entry so the change has a documented "why" alongside the "what". Auditors read this trail during evidence review — empty or boilerplate reasons weaken the governance narrative.

A group of agents derived from their `agent_id` suffix — bare IDs land in cohort 1, IDs ending in `-2` / `-3` / `-N` land in their numbered cohort. Operators use cohorts to verify a batch of fresh seed agents together after a demo re-seed (each re-seed bumps the cohort counter so prior chains aren't replayed). Auditors usually pick "All cohorts" so the verification report covers every agent in scope.

Quick-toggle pills that narrow the table to a specific operational concern — health, risk tier, or forensic gap. Mutually exclusive across the three groups (health / risk / forensic); the "All" pill clears every cohort filter. Operators use these for triage workflows; auditors typically clear all cohorts to see the full inventory.

One running copy of the Wytness Collector container, identified by the collector id it registers under and shown with its label and image version. An operator runs one instance per boundary they want capture to stay inside, and reads this block to confirm the container is alive and which sources it is polling. An auditor uses the instance identity to tie a set of collected events back to a named piece of infrastructure the customer controlled.

When this usage table was last calculated. The figures are cached briefly on the server rather than recomputed on every page load, so a model call made moments ago may not appear until the cache turns over. An operator watching a change land should read this stamp before concluding that capture is not working.

An outbound push channel that forwards Wytness anomaly alerts to a system you already operate — your SIEM, ITSM queue, chat room, or a custom HTTPS endpoint. Each connector pairs a provider (Sentinel, Splunk HEC, ServiceNow, Slack, or generic webhook) with a trigger mode and credentials, then sends a single HTTPS POST per qualifying anomaly alert. Operators configure connectors so anomaly alerts show up in the tools their team already watches; auditors verify that delivery is reliable, retried on failure, and authenticated end-to-end.

What a connector sends downstream. Every provider — Sentinel, Splunk, ServiceNow, Slack, and the generic webhook — forwards anomaly alerts only: a compact payload with severity, rule name, agent ID, and description that never includes the underlying event body, tool parameters, or any PII. The generic webhook delivers the same alert as a CloudEvents 1.0 envelope for pipeline consumers. A full audit-event feed is not offered; auditors can verify that connectors never ship raw payloads.

Whether this connector is currently receiving dispatches. The pill is a toggle — click it to flip between Active and Disabled without losing the saved credentials and config. Operators disable a connector when a downstream system is under maintenance or being deprecated, then re-enable once it is ready again. Auditors check that no connector has been silently disabled for longer than its declared review interval.

The framework-specific table that maps each regulator control (e.g. SOC 2 `CC6.1`, ISO 27001 `A.12.4`, EU AI Act `Art. 12`) to the underlying Wytness evidence that satisfies it. Operators glance at the Status column to confirm every control has supporting evidence in this period; auditors trace each `Pass` back to the originating events or configuration records named in the Evidence column. A `No Data` status means the period under review contained no events matching the control's scope — typically benign but worth recording in the auditor's working papers.

Chat-style replay of the session, pairing each user prompt with the assistant's response and interleaving the tool calls the agent made along the way. Multi-turn sessions are grouped by prompt; time gaps over 30 minutes inject a separator so a multi-day conversation reads naturally. PII fields stay tokenised until the operator unlocks the Reveal toggle with their browser-held key. Operators use this view for support context and incident triage; for forensic detail (chain-link verdicts, hashes, span structure) switch to the Trace tab.

The Wytness-assigned ID that ties this event to its ingest request — surfaces in backend logs, error responses, and the operator's investigation tools. Use it to correlate this event with ingest-side diagnostics. Not load-bearing for compliance evidence.

Historical record of spend spikes flagged by AGT's `agent_sre.cost.CostAnomalyDetector` — sudden departures from an agent's recent cost baseline (token-burst, runaway loops, model upgrade without budget bump). Each row shows when the spike fired, the agent involved, the anomaly type, and the dollar delta against the rolling baseline. Operators use this to spot regressions; auditors use it as evidence that runaway cost is detected and recorded rather than absorbed silently into the invoice.

Active alert list for agents whose cycle-to-date LLM spend has crossed their configured per-agent budget. Sourced from AGT's `agent_sre.cost.CostGuard` primitive once the backend extractor lands; until then the panel renders an honest empty state. Operators triage by pausing the offending agent, raising its budget, or applying the optimiser suggestion. Auditors verify that every alert has either a documented operator response or an explicit suppression.

The cadence on which you replace the credentials Wytness uses to write to your private storage. ClickHouse user passwords and the Azure service principal client secret are independently rotatable from this page — credential updates do not require re-running the wizard or migrating data, and they do not invalidate any historical archive. The Update credentials button replaces the active ClickHouse password in-place and runs a connection test before accepting the change; if the test fails the prior credential is kept so ingest does not break. For the Azure SPN, generate a new client secret in Azure Portal first, then paste it here. Rotation cadence is a security-policy decision — auditors typically expect ≤ 90 days for production credentials.

Independent cryptographic verdicts on this event — envelope signature, chain hash linkage, and (where applicable) HMAC chain check. Computed on demand against the customer's public key and the immutable storage record. A red verdict here is the strongest possible tampering signal; auditors require all three verdicts green for evidence acceptance.

The recompute of this event's own canonical content hash — Wytness rehashes the stored event and compares against the AGT-supplied Entry hash. A green AGT hash-chain verdict requires this recompute equal to the stored Entry hash; a mismatch is the cryptographic signature of tampering between ingest and verification time.

The encryption-key envelope you hold yourself for the audit archive, instead of letting Microsoft Azure manage it transparently. With a customer-managed key (CMK), the AES-256 envelope wrapping every blob is itself encrypted by a key stored in YOUR Azure Key Vault — Wytness reads through the SPN, but if you rotate or revoke the Key Vault key, the blob becomes unreadable everywhere, including by Microsoft. The trade-off: stronger non-repudiation posture for auditors, but losing the Key Vault key means losing the archive (no recovery path). Microsoft-managed encryption is the default and works for most operators; CMK is a forthcoming optional layer for customers with explicit key-custody requirements.

The data the tool returned to the agent. Same PII handling as Action: tokenised at the customer edge by the SDK before the payload is signed and posted. Auditors verify that high-risk data flows (e.g. customer records leaving the database) appear here with the expected outcome and that no cleartext PII was written to the trail.

A one-time copy of your historical events out of the Wytness shared store and into your newly activated private ClickHouse + archive. New events have already started flowing to your private storage at activation time — migration is only about bringing the back-catalogue forward. The job runs in three phases: copy (ClickHouse rows + chain hashes, then your archive files — events and alerts), verify (re-walk the chain end-to-end on the destination, and confirm every archive file arrived intact), and clean (delete the source rows and archive files from Wytness shared storage). Clean is a separate confirmation step so the source survives the verify phase as a safety net, and it stays locked until both Chain Verified and Archive Copied are green. Progress is shown in events copied / events total, plus archive files copied / total. Chain Verified appears when the destination chain hash matches the source chain hash byte-for-byte — auditors want this proof that the migration did not silently corrupt history. Archive Copied appears when the file-by-file archive comparison passes.

What Shield does when a policy's selector matches an agent action. Three outcomes today: allow (pass), queue (route to a human), or block (reject). The decision applies only when the policy's mode is enforce; in observe mode the decision is recorded but the action still passes. Auditors trace blocked and queued decisions back to the policy that fired them for evidence packs.

The letter grade AGT's PromptDefenseEvaluator assigned to the prompt at the time of this anomaly. Source: `agent_compliance.prompt_defense.PromptDefenseEvaluator` (AGT 4.0). The grade summarises how many OWASP LLM-injection vectors the prompt defended against; hover the chip to see the score out of 100 and the vector coverage ratio. Operators chase D / F grades first; auditors verify defence coverage trends across the audit period.

The state of a single delivery attempt as it sits in the delivery log. Each row tracks one event-to-endpoint dispatch through pending → retrying → delivered or failed. Operators sort by Status to find what is currently stuck; auditors verify that no event has been left in `failed` without operator acknowledgement and that retried attempts eventually settle.

`status=denied` means a human-in-the-loop reviewer rejected the action via an approval prompt. The tool didn't run (or was rolled back if it had pre-staged work). Distinct from `blocked` (automatic policy) and `failure` (runtime fault) — `denied` is a recorded human decision. Renders as a rose-toned red badge with the `Denied` label; the event row gets a danger tint (`var(--wyt-danger-bg)`) so the rejection is visible at a glance. In manual-mode runs, denial typically short-circuits the workflow — subsequent steps don't fire. The denial itself is a signed audit event in the chain; the rejected action's payload is preserved as evidence.

A one-line, human-readable explanation produced by the rule that fired — e.g. "Tool `db.write` first seen on this agent in 30 days" or "Error rate 24% over last 100 events". Description content is rule-specific and includes the exact thresholds or values that crossed the rule's boundary, so an operator can usually triage without opening the detail drawer. Auditors quote this column verbatim in incident write-ups.

Optional free-text explanation of what the policy is for and why it exists. Use it to capture the control's intent in plain language — the regulator-facing summary an auditor reads before drilling into the selector. Good descriptions name the risk being mitigated and the framework or internal control the policy maps to. Empty descriptions are accepted; auditors will instead lean on the policy name and the selector preview.

Count of distinct tools that have exercised this permission within the active time window. Two tools calling the same scope show as `2` even if one called it once and the other called it ten thousand times — this is a coverage signal, not a volume signal. A high distinct-tool count on a sensitive permission is a flag that the scope has spread further than intended; a count of `1` makes a clean candidate for tightening (revoke and re-grant on the single tool that needs it).

How long the tool invocation took to complete, in milliseconds. Rendered in ms / s as appropriate. Long durations on a tool that normally runs fast can indicate upstream service degradation, agent looping, or a malicious payload that's burning compute. Outliers feed the anomaly engine's behavioural baseline.

The master switch for a policy, independent of its mode. A policy can be in enforce mode but switched off — in which case nothing happens. Operators flip this to quickly mute a policy without losing its selector + decision configuration. Auditors verify that every documented control has an `On` policy in enforce mode; an `Off` policy is evidence the control is currently inactive.

The credentials you paste into the storage setup wizard (ClickHouse password, service principal client secret) are encrypted with AES-256 before being written to the Wytness control-plane database, using a key held in Azure Key Vault. The plaintext is never logged and is never returned by the configuration API after save — the form shows "Leave blank to keep existing" on subsequent edits because the cleartext is unavailable to the UI. The audit-event payloads themselves (the ones written into your Azure Blob archive) are additionally encrypted by Azure Storage Service Encryption with Microsoft-managed keys by default; customer-managed keys are available on Azure if you want to hold the encryption-key envelope yourself.

The X25519 keypair the wrapper uses to encrypt the per-event PII token map. The public half is registered with Wytness and used by the wrapper to seal token maps in transit; the private half stays in your browser and decrypts revealed PII via the Reveal panel. Generated in-browser using TweetNaCl — the private key never reaches Wytness servers. Only the public key plus a first/last-4-char hint of the private key are stored. Auditors verify that production traffic carries sealed token maps and that Wytness has no path to reverse them. Distinct from the signing key: encryption protects privacy, signing proves non-repudiation.

A "Verified-tier" identity badge surfaced on AgentDetail when the AGT 4.0 runtime has cryptographically verified the agent's identity via a Microsoft Entra-signed JWT. Entra (Microsoft's identity platform) signs short-lived JWTs that AGT 4.0's mesh-relay WebSocket layer presents on every connection; verification proves the agent is currently authorised by your Entra tenant, not just self-attesting its DID. This is a stronger identity proof than the default open-trust DID model and pairs naturally with Conditional Access policies on the human sponsor. The chip is only rendered when AGT reports a successful verification — its absence means the agent runs under the DID-self-attest default (still a valid identity model, just a weaker proof). New in AGT 4.0. Source: extended `agentmesh.identity` verification.

The SHA-256 hash AGT computed over this event's canonical content — the leaf identifier in AGT's Merkle-tree (Python runtime) or flat link chain (TypeScript runtime) audit ledger. Any change to the event's content changes this hash. Pairs with the Previous hash to verify cryptographic linkage to the prior event. A Crypto verdict mismatch on the AGT hash chain layer roots back to a discrepancy between this stored value and a fresh recompute.

The fingerprint of the customer-held Ed25519 public key the Wytness wrapper used to sign this event's envelope. Wytness uses the fingerprint to look up the registered key when re-verifying the signature; the private half lives in the customer's browser or SDK environment and never reaches Wytness servers. Click to open the key in Keys for rotation history and registration status.

A per-row verdict from re-verifying the Wytness envelope signature against the customer's public key. The signature covers the canonical JSON of the event payload; a green tick is non-repudiation evidence that the agent owner attested to this specific event. A red cross is the strongest tampering signal Wytness can surface — investigate on the Verify page.

Which version of the Wytness per-event envelope was used to sign this event. Envelope version 2 widened the signed payload from `data`-only to the full canonical JSON of `{data, id, time, type}`, closing a replay window. Auditors verify version 2 across all production traffic.

Which deployment environment the agent was running in when the event was emitted. Reported by the SDK from its configuration. Auditors use the environment filter to scope evidence packs to production-only — staging or development events typically don't count as compliance evidence.

The error code the tool raised when it failed or timed out — short symbolic name (e.g. `TIMEOUT`, `AUTH_DENIED`, `RATE_LIMIT`) captured by the SDK from the tool's exception. Renders `none` on successful events so an empty cell never means "unknown". Auditors cross-reference error codes against the tool's documented failure modes to spot novel failures and silent regressions.

`error_count / total_events` as a percentage within the active window. Red badge when over 10% — a heuristic threshold that flags agents likely experiencing regressions or upstream outages. Operators use it as the primary at-a-glance reliability signal; auditors look for sudden rate changes after deployments as evidence for incident timelines.

Count of events with `status = failure` or `status = timeout` emitted by this agent within the active window. Pairs with Total events to form the Error rate. Operators use it to triage which agents need investigation; auditors verify that error remediation cadences match the SOC 2 / SLA commitments.

An estimate of what this model cost you at your own LLM vendor this cycle — Wytness does not bill it and never sees your vendor invoice. It is computed from captured tokens at each rate, so it will differ from the invoice wherever committed spend, included allowances, or volume discounts apply, none of which are modelled. Where no price is on file the tokens are still recorded and the dollar figure is left blank rather than guessed from a similarly named model.

The unique identifier assigned to this audit record at ingest. Wytness uses the SDK-generated UUID where present and falls back to a server-side mint for legacy paths; either way the ID is stable for the lifetime of the event and is the canonical handle for cross-referencing in exports, deep links, and chain-of-custody walks. Truncated to the first eight characters in compact lists for readability; click the truncated value to jump into the Events page deep-linked to that specific row. Auditors cite this ID when raising a specific event for review.

The AGT event-kind chip — the high-level taxonomy AGT classifies the event under (tool invocation, policy decision, identity event, etc.). Sourced from the AGT runtime; semantics defined by AGT, not Wytness. Auditors use the distribution of event kinds to confirm the agent's behaviour profile matches the documented design.

The canonical status vocabulary for every audit event Wytness records. Six named values cover the lifecycle of an agent tool call: nominal completion (`success`), runtime errors (`failure`), exceeded deadline (`timeout`), policy interception before execution (`blocked`), human reviewer rejection (`denied`), and the in-flight wait before a HITL gate resolves (`pending`). Any other string is preserved on read for forward compatibility but renders as a neutral badge. Colours map success to green, failure / denied to red, timeout / blocked to amber, and pending to neutral with a brand dot. Locked by `docs/facts/event-status-semantics.md`; drift caught by `tests/test_event_status_vocabulary_parity.py`.

Area chart of how many audit events landed per bucket across the active window. Hour buckets for the 24h window, day buckets for 7d / 30d / all. Shape matters more than absolute values — a flat plateau is steady-state, a sharp drop suggests an outage or upstream connector failure, and a sudden spike can indicate a rogue agent, a load test, or a connector backfilling. Click into Events to walk individual rows when a feature stands out.

Count of audit events recorded within this session — every tool call, prompt, response, and framework callback the agent emitted between the session opening and closing. Distinct from the agent-wide lifetime total: a long-running session may produce hundreds of events, while a one-shot session can emit just two. Operators sort by this column to find unusually long or chatty sessions; auditors check the count against the conversation transcript to confirm no events were silently dropped.

Count of audit events emitted by this agent or tool that carry the permission, scoped to the active time window (24h / 7d / 30d / all). Switch windows to compare a permission's recent intensity against its lifetime use. Sort descending to surface the loudest exerciser of the scope first — usually the place where a Shield policy would have the most blast radius for a single change. Auditors use the per-window count to confirm rollback claims (post-revocation windows should drop to zero for the revoked caller).

The underlying audit records that satisfy each mapped control — typically a short description of which event stream, log type, or configuration field carries the proof (for example, "Every agent event signed with Ed25519 envelope; 99.8% verified" or "Per-event chain validation; 0 breaks in period"). Operators read the Evidence column to confirm the pack tied each control back to real data rather than a placeholder; auditors trace each entry to the source artefact (event row, signing key, anomaly rule) referenced in the Appendices.

The auditor-ready bundle assembled by this page from your audit trail — a printable PDF (via the browser print dialog) plus the underlying JSONL records. Operators generate a pack at the start of every audit or surveillance period; auditors read the pack as a self-contained reviewable artefact (cover page, control mapping, agent inventory, anomaly report, cryptographic proof, sample events, methodology). Packs are point-in-time snapshots, so a new pack each quarter is typical for SOC 2 surveillance and after every material configuration change.

The directed graph of every agent-to-tool and agent-to-agent call inside one session. Nodes are agents or tools; edges record `calls` (parent invoking child) and `returns` (child handing control back). The first-pass view renders the graph as an indented list (root call at the top, nested children pushed right) so the call sequence is scannable at a glance. A future iteration may upgrade to a true SVG tree once customer feedback says so. The graph is the Trace tab's Graph layout — the structural cousin of the Tree layout's chronological span tree.

The AGT 4.0 OpenTelemetry span tree for this session, rendered as the Trace tab's Tree layout. Each span is one tool invocation or agent step; nested children show calls a tool made into sub-tools. Spans carry their own start/end timestamps, status, and `agt_trace_id` correlation key — making it possible to follow a single request as it hops across agents, frameworks, and external services. Operators use the trace view to spot serial bottlenecks and parallel-execution patterns; auditors use it to reconstruct the exact order of operations during an incident replay.

The opening KPI block on every generated pack — total events, active agents, anomalies detected, error rate, chain-valid versus chain-broken agents, average duration, and total errors. Operators use it as a fast read-out of the period under review before sending the pack to an auditor; auditors compare the figures against the corresponding sections (Agent Inventory, Anomaly Report, Chain Verification) to confirm the headline numbers reconcile. Any mismatch between the summary and the underlying tables is a finding.

Wytness records the permissions an agent reported on each tool call — the scopes it actually exercised at runtime. That is a lower bound on capability: an agent may hold scopes it has not yet used, and the platform does not infer granted scopes from upstream OAuth, IAM, or MCP grant records today. So an empty list does not prove the absence of capability; it only proves no recent use. Operators rely on this distinction when scoping a revocation — the reverse-lookup tells you the observed blast radius, not the theoretical one. Auditors call out the gap explicitly in evidence packs so reviewers do not over-trust the list as a complete capability inventory.

The AGT 4.0 expanded `AuditEntry` fields — additional structured metadata AGT writes on every event (e.g. agent lifecycle phase, framework adapter, protocol facets). Surfaced verbatim from the AGT runtime; auditors familiar with AGT's audit schema can read this directly to cross-check against AGT's own audit verifier.

Timestamp of the first audit event that linked this agent or tool to the permission within the active time window. Answers "when did this caller first exercise this scope?" — useful for spotting brand-new uses of a sensitive permission, or for confirming that a rollback actually stopped a caller from invoking the scope. Auditors pair First seen with Last seen to scope a permission's effective use window during a forensic review.

Human-readable label of the wire format Wytness received this event in — "Wrapper (Python)", "Wrapper (TypeScript)", "AGT audit", "AGT event", etc. Decoded from the underlying `source_format` enum for readability. Auditors confirm the format matches what the customer's deployed SDK is expected to emit; a drift here points at SDK rollout gaps or shadow ingest paths.

Which agent framework the AGT runtime detected at registration. Each framework has its own adapter inside AGT that normalises its events into the canonical audit schema. Operators use this to inventory their framework footprint; auditors check that the adapter's audit fidelity matches the regulator's evidence requirements for that framework.

The compliance regime the pack is generated against. Operators pick the framework that matches the audit in progress (or the customer-procurement question being answered); each framework drives a different control set and citation style on the pack's Control Mapping section. Auditors verify that the framework label on the cover page matches the engagement's scope statement.

Absolute date bounds that narrow the table to events whose timestamp falls between From and To; either side may be left open. Operators pin an incident window before drilling into rows; auditors reproduce the exact evidence period by sharing the URL, which carries both bounds. Unlike the relative time-window pills on other pages, these are fixed calendar dates — the result set doesn't shift as time passes.

The generic connector posts CloudEvents 1.0 JSON to any HTTPS endpoint you control — typically an internal pipeline, data warehouse loader, or aggregator service that already understands CloudEvents. Configuration is two fields: the endpoint URL and a shared HMAC secret. Each request carries a Wytness-Signature header your receiver verifies with HMAC-SHA256 to confirm the body has not been tampered with in transit. Like every provider, it forwards anomaly alerts only — the CloudEvents envelope makes the same alert easy to consume in pipelines; a full audit-event feed is not offered.

The canonical "this is what success looks like" recording for an agent — promoted from a real session that an operator vouches for. A future replay measures the agent's current outputs against the golden trace's recorded inputs to catch silent regressions when prompts, models, tools, or policies change. Each agent can have at most one golden trace at a time. Sessions promoted to golden status carry a green checkmark badge in the detail header.

The principal — operator, supervisor, or system — that issued the scope token in effect for this event. Establishes the authority chain: the agent acted with permissions granted by this identity at this moment. Auditors require a real principal here; a generic value like `system` or `auto` is a flag to confirm the autonomous-issuance policy was correctly applied.

A traffic-light summary of whether this connector is actually delivering. Computed from the most recent success and error timestamps on the endpoint — whichever is more recent wins. Operators triage Failing rows first; auditors verify that no Failing connector has been left unattended past its review window and that Idle connectors past a configured age get reviewed for deletion.

How long ago this collector last reported in. The container posts a heartbeat every poll cycle carrying only non-secret source descriptors and health counters — never credentials — and the badge turns amber once more than ten minutes have passed, which usually means the container has stopped rather than that the sources went quiet. An auditor reads heartbeat continuity as evidence that capture was running across the period, separately from whether any given source produced rows.

The shared secret the wrapper uses to deterministically tokenise PII fields across sessions — the same input always produces the same token, so cross-session compliance queries can still match without ever seeing the plaintext. Generated in-browser; Wytness stores only a first/last-4-char hint. Pass to the wrapper as `pii_hmac_secret` (Python) or `piiHmacSecret` (TypeScript). Auditors confirm the secret is rotated on a defensible cadence and that rotations are logged in Key History — rotating breaks pseudonym continuity, so events before and after rotation produce different tokens for the same underlying value.

The shared secret the generic webhook connector uses to sign each outbound HTTPS request, so the receiver can verify the body has not been tampered with by anything between Wytness and the endpoint. Wytness sends a Wytness-Signature header containing HMAC-SHA256 of the request body using this secret; your receiver re-computes the same HMAC and rejects requests whose signature does not match. The secret is stored encrypted server-side and only the entered fingerprint hint is shown after creation. Auditors verify that signature verification is actually enforced on the receiving side and that the secret is rotated when an integration partner changes.

The HTTP status code the downstream system returned on the most recent attempt for this delivery, or `—` if no response was received (network error, timeout, or DNS failure). 2xx codes count as Delivered; everything else triggers the retry-backoff scheduler. Operators read this column alongside the error message to decide whether a failure is a config problem (`401`, `403`, `404`), a downstream outage (`5xx`), or rate limiting (`429`).

The chain of authority behind this agent — each IATP link records which parent DID delegated which capabilities to which child, with creation and expiry timestamps and a link hash. Operators walk the chain upward to find the sponsoring parent when an agent misbehaves; a root agent shows no chain. Auditors verify the agent only exercised capabilities a parent actually delegated, and that no link in the chain was expired at the time of action.

Who emitted the event and when. Identifies the agent, the deployment environment, and the precise timestamp. Auditors anchor every action to an identifiable principal at a specific moment; the Identity section is the first thing a reviewer reads to attribute responsibility.

The container-level Azure setting that enforces WORM by rejecting deletes and overwrites until a retention window expires. Two states exist on Azure: Unlocked (operator can shorten or extend the window) and Locked (operator cannot weaken the policy — only extend retention). Auditors want a Locked policy on the archive container; an Unlocked policy is not evidence of tamper resistance because the storage-account owner could shorten the window the day before an investigation. Wytness does not configure this policy on your behalf — it is set by you in Azure Portal so the chain of trust does not run through Wytness's hands.

How many of the sampled events an auditor can re-check without Wytness, against how many were sampled. An event is independently verifiable when it carries a customer signature and the exact bytes that signature covers were retained; the pack states per event which of three cases applies when it is not — no customer signature at all, the message erased under a right-to-erasure request, or an event captured before those bytes were kept. The ratio is deliberately not a pass mark: it says how much of the record rests on your own key rather than on a verdict Wytness recorded, and the unverifiable remainder is explained rather than hidden.

Tokens sent to the model across every captured call this cycle — the prompt, the conversation carried forward, and any tool results fed back in. Input volume is usually where unexpected spend comes from, because history grows with a conversation while the visible question stays short. Cached input is counted separately, so this figure is the traffic that was priced at the full input rate.

Donut chart of this tool's invocations broken down by the data-classification tag captured on the agent's input payload — typically one of `public`, `internal`, `confidential`, `restricted`, or `pii`. The classification is set by the SDK middleware (or AGT) when it tokenises the payload; rows without a classification roll into `unknown`. Operators use this to spot tools that are processing more sensitive classifications than the risk tier or Shield policy assumes. Auditors look for unexpected `restricted` or `pii` slices on tools the documented design says should never see them.

A SHA-256 hash over the tool's input payload, taken by the SDK before any tokenisation or transport. Lets auditors verify the inputs the agent observed match what the customer's system actually sent, even when the payload itself has been redacted, tokenised, or aged out. Hash-only retention is the cheapest form of evidence and the default for high-volume tools.

Distinct `agent_instance_id` values seen for this agent. `0` means a legacy SDK that doesn't emit per-instance IDs; `1` is a single-host agent; `>1` means the same agent ID is running on multiple hosts (intentional fleet deployment) or — rarely — colliding identifiers across unrelated deployments. Auditors investigate unexpected jumps in instance count as potential identifier-collision signals.

Number of times this tool was invoked across all agents within the active time window (set by the page-level Window selector). Operators sort by this column to find the loudest tools — those are the ones whose policy and identity model need the most attention. Auditors compare invocation distributions against expected baselines to spot abnormal usage bursts and sudden silences (a tool dropping to zero often means a deployment broke its call site).

The audit log of key actions for the currently selected tab — creations, rotations, and revocations, each with actor, timestamp, and (for revocations) the operator-supplied reason. Filtered to the current tab so the API tab shows only API-key actions and crypto tabs show only key-rotated entries for that key kind. Operators use this to confirm a rotation actually persisted; auditors read this to attest the rotation cadence and to confirm every revocation carries a defensible reason. The history is immutable — it lives in the same audit trail as the rest of the ledger and cannot be edited from the UI.

The compromise pathway. Use revocation only when you believe the private key has leaked. Sets a `revoked_at` timestamp on the key; events signed *before* that timestamp remain legitimate (the retired key still verifies history), events signed *after* fail envelope verification and surface as tampering on the Chain page. Requires typing `REVOKE` + password + a free-text reason — the reason is written into Key History so the auditor can later see why a revocation was triggered. If the revoked key was the scope's default, the newest other active key in the same scope auto-promotes so the scope always has a default while at least one active key remains. Distinct from rotation: rotation is routine and assumes the prior key is still trustworthy; revocation is a security event and breaks the trust chain forward.

Replacing an active key with a freshly generated one on a routine schedule. Rotation retires the prior key but does not invalidate its historical signatures — events signed before the rotation continue to verify against the retired public key. New events must be signed by the new private key. For signing keys, you can also hold multiple active keys in the same scope at once (e.g. "dev env" alongside "prod"); generating a key in a non-empty scope is an "Add another" action and doesn't retire anything. Operators rotate to limit the blast radius of an undetected leak; auditors confirm the rotation cadence in Key History matches the security policy. Requires typing `ROTATE` + password to confirm — rotation of an encryption key or HMAC secret has cross-cutting effects that the modal spells out before you proceed.

Which agents a signing key applies to. Org-wide keys verify every agent that doesn't have its own; per-agent keys are bound to a specific `agent_id` via the "Apply to" dropdown when generating. After registering an agent's first specific key there's a 30-day grace window during which both that agent's key and the org-wide key are accepted on its events, so wrappers can be updated without dropping events. After 30 days only the agent-specific key applies. Operators pick per-agent scope when the agent runs in a more sensitive context or on a different host than the rest of the org; auditors check that high-risk agents have dedicated keys rather than sharing the org-wide fallback.

An audited record of operator kill decisions for an agent. Confirming the action records who decided to kill the agent, why (manual, behavioral drift, rate limit, ring breach, or a timeout), and when — it does not terminate the agent; actual termination requires the agent's own runtime to act on the recorded intent. The history lists every recorded kill event so auditors can tie each decision to the incident timeline.

The most recent successful dispatch (OK) and most recent failed dispatch (ERR) for this connector, each timestamped. Both lines render whenever they exist, so you can see at a glance whether the connector recovered after its last error or is still in a broken state. Operators use this to confirm a recent fix took effect; auditors compare the OK timestamp against the delivery SLA the customer has committed to internally.

How long ago this source last produced a row for the collector to pick up. The value survives collector restarts, so a container that has just come back up does not falsely report a source as freshly active. This is the timestamp silence is measured from, and an auditor reads it as the edge of the evidence for that capture channel.

Timestamp of the agent's most recent audit event. Answers "is this agent still alive?" — long gaps relative to the agent's normal cadence are an early signal of a stopped runtime, removed deployment, or upstream issue. Auditors use it to confirm that retired agents have actually stopped emitting events on the recorded sunset date.

Timestamp of the most recent successful chain-verification run for this agent. Pairs with Last seen — Last seen answers "is this agent still alive?", Last verified answers "do we still trust this chain?". Null until verification runs (operator-triggered on Verify, or via a scheduled job). Auditors compare against the period under review; an old or absent Last verified means the chain attestation is stale and needs to be re-run before the evidence pack closes.

How the org's subscription is provisioned and charged. Most customers run on Stripe self-serve — that's the default; the Compare plans grid and Update card flow only show when this is the case. Marketplace subscriptions surface a banner that links out to the cloud-provider portal because plan changes and payment live there, not in Wytness. Manual billing is the Enterprise + custom-contract path: the in-app surface is read-only and surfaces a support email instead of a checkout button.

The AGT 4.0 `MCPSecurityScanner` result for this tool's MCP server — surfaces tool-poisoning, rug-pull, cross-server-attack, and hidden-instruction patterns. Operators triage flagged tools immediately and inspect the per-threat panel before next deployment; auditors verify that any tool reaching production has at least one Safe scan within the framework's review cadence (typically 30 days).

The Microsoft Sentinel connector posts to the Azure Logs Ingestion API, which routes the payload through a Data Collection Rule (DCR) you create in Azure into a custom Sentinel table. Configuration takes seven fields — tenant ID, client ID and secret for an Entra app registration that has been granted "Monitoring Metrics Publisher" on the DCR, the Data Collection Endpoint host, the DCR immutable ID, the stream name, and the fully-formed ingestion URL. The client secret is stored encrypted server-side. Auditors verify that the Entra principal is scoped only to the DCR it needs to write to and that the secret is rotated on a defensible cadence.

How aggressively Shield acts on a policy's decision. Observe-before-enforce is the canonical workflow: author the policy, watch it run in observe mode against live traffic, confirm the decision matches intent, then flip to enforce. Auditors expect production-critical policies to sit in enforce mode with documented sign-off; observe-only policies are evidence of monitoring, not enforcement.

The vendor model string exactly as your agents called it, never normalised or grouped. Two versions of the same family appear as two rows, because they are priced differently and an operator investigating a cost change needs to see the version move. An auditor reads the model identifier as part of the record of which system made a decision, which several frameworks expect to be stated precisely rather than by family name.

The human-readable label for a Shield policy. Picked by the operator at creation time; surfaces in the policy list, decision logs, evidence packs, and approval routing copy. Keep names short and intent-led — "Refunds over $500 — queue for review", "Block production secrets in prompts". Auditors read policy names alongside the selector to confirm the control's stated purpose matches what the selector actually intercepts.

A flat per-million-token rate you set for a model, replacing the vendor's list price in every cost estimate for it. Owners and admins can set input, output, cache-read and cache-write rates independently, and rows priced this way are labelled "your rate" so the substitution is never silent. It models a flat discount only — tiered and committed-spend agreements are not represented, so an estimate under one of those will still differ from the invoice.

An optional recurring time window during which the policy makes a different decision. Operators configure a timezone, a start and end time (HH:MM, wraps midnight if start is after end), and the active days of the week. During the window the override decision applies; outside it the primary decision applies. Common pattern: allow refunds during business hours, queue them for review overnight and on weekends. Leave it unset for a policy that should make the same decision around the clock. Auditors check off-hours overrides against documented business-hour controls and on-call escalation policy.

Whether the Overview page is showing the dashboard or the first-run setup wizard. The wizard appears only when your org has never ingested an event and you haven't dismissed it. The "Setup wizard" link in the header re-opens the wizard on demand — useful when adding a second SDK or onboarding a teammate — and is always available regardless of current state.

The human operator on whose behalf the agent acted, as reported by the SDK at event time. Typically a user ID, email, or service-account name resolved from the calling context. Auditors trace agent actions back to a responsible human; an unattributed value here is acceptable for fully autonomous flows but should be a deliberate configuration choice, not silent drift.

The named human operator accountable for the agent's behaviour under EU AI Act Article 13 and ISO 42001 §7. Set on Registry as part of agent classification; surfaced on the dashboard as the "Operators assigned" stat. Auditors verify that every production agent has a named human owner — unassigned agents indicate a governance gap that blocks evidence acceptance.

Per-agent spend-reduction recommendation produced by AGT's `agent_sre.cost.CostOptimizer` — examples include swapping a high-cost model for a cheaper sibling, enabling prompt caching, or shortening system prompts. Each row carries the agent, the suggested change, and an estimated monthly saving in USD. Suggestions are observational; operators apply them by editing the agent's runtime configuration. The list hides until AGT emits suggestions for the org.

What happened at the end of the action — success, failure, or timeout — plus any error message. Combined with Action and Data, Outcome closes the who/what/result chain that an auditor walks to verify an agent's behaviour.

Tokens the model generated across every captured call this cycle. Output is priced well above input at most vendors, so a small number here can dominate the cost column. An operator comparing two models on the same workload reads output tokens alongside estimated cost, since the cheaper per-token model is not always the cheaper model.

Donut chart of this tool's invocations broken down by where the output went — typically the downstream system or service named on the agent action (e.g. `slack`, `stripe-api`, `internal-cache`). The destination is read from the audit payload's `outputs.destination` field; events without one roll into `unknown`. Operators use this to confirm a tool's output really only fans out to the documented set of destinations. Auditors flag tools with an unexpectedly wide destination distribution as candidates for tighter scope permissions.

A SHA-256 hash over the tool's output payload, taken by the SDK before tokenisation or transport. Lets auditors verify the data the agent received back from the tool matches what the tool actually returned, even when the payload has been redacted or aged out. Together with Inputs Hash, gives content-integrity coverage for the tool invocation even without the payload itself.

Above-quota event consumption in the current billing cycle, expressed in dollars at the plan's per-event overage rate. The card shows accumulated overage to date; the projection banner forecasts the end-of-cycle total based on current pace. Operators flip to a higher tier once projected overage exceeds the upgrade delta; auditors verify the recorded overage matches the count of above-cap events for the period.

The internal owner — typically the team lead or service owner — listed as responsible for the tool's behaviour and remediation. Set manually on the tool detail page (the SDK never populates it). Operators use Owner as the routing field for incident-response handoffs; auditors check that every high-risk tool has a named, current owner so accountability is unambiguous in evidence packs.

The JSON arguments the agent passed to the tool — the exact inputs the tool received at runtime. Rendered with structure so auditors can read field names and values directly. Same PII handling as Prompt: tokenised at the customer edge, revealed only with the browser-resident key. A common audit step is to confirm parameters match the documented contract for the tool.

The card on file Wytness charges at each renewal and for accumulated overage. Only the brand and last four digits are stored in Wytness; the full card lives in Stripe's vault. "Add payment method" opens a Stripe-hosted setup session — Wytness never sees the PAN. Customers on a paid plan need a card on file before the trial ends, otherwise ingest hard-stops at the cap with a 402. Update card and Cancel subscription both deep-link to the Stripe Customer Portal where Stripe handles the destructive actions directly.

`status=pending` means the tool call is paused at a human-in-the-loop gate, waiting on reviewer approval. The tool hasn't run yet (and may never run, if the reviewer denies). Renders as a neutral badge with a brand-coloured dot and the `Pending` label; no row tint — the dot is the signal. When the reviewer approves, the same event row transitions to `success` (tool ran) or `failure` (tool ran but errored); on deny, it transitions to `denied`. The Wytness embed dashboard surfaces a `Pending review` HITL pill alongside the status badge so operators can spot which event is awaiting decision.

Which connector providers your plan tier lets you configure. Connectors are a Business-and-above feature: Business and Enterprise unlock the full set — Microsoft Sentinel, Splunk HEC, ServiceNow, Slack, and generic — while Starter and Growth have no connector access. Providers your plan does not include are hidden from the tab row, and the Add button is disabled when no provider is selectable. Existing endpoints on a provider your plan no longer covers surface as stranded endpoints; they stay deletable until you either upgrade or remove them.

Filter events by the scope permission the agent held at the time of the action — e.g. `db:read`, `email:send`, `tools:write_file`. Permissions are reported by the SDK from `WYTNESS_AGENT_PERMISSIONS` or per-tool `scope_permissions`. Use this filter to scope an investigation to a specific privilege; auditors use it to verify least-privilege patterns.

The permission string the SDK reported on the original tool call — typically a colon-delimited scope like `db:read`, `email:send`, or `anthropic:messages:create`. The shape is free-form text: Wytness does not impose a grammar, so the values you see here are whatever the agent SDK or framework declared at runtime via `WYTNESS_AGENT_PERMISSIONS` or per-tool `scope_permissions`. Auditors normalise the scopes during evidence-pack assembly and call out non-conforming values as a least-privilege finding.

The Permission Detail page answers the inverse question of the Permissions tab on Agent and Tool pages. Those panels answer "which permissions does this agent or tool exercise?". This page flips the question: given one permission name, which agents, which tools, and which recent events have exercised it. Useful when a permission is suddenly broad (audit trail review), when a new scope is added (rollout monitoring), or when a permission needs to be revoked (blast-radius assessment before removal). Auditors use this view to verify that a privileged scope is only exercised by the expected callers.

Customer-held key encryption applied to sensitive payload fields before the event leaves the agent process. Wytness servers see only opaque tokens; the operator's browser holds the only key that can reverse them. Auditors confirm that production traffic carries tokenised payloads — cleartext PII in the trail breaks the customer-held-keys guarantee.

The CTA shown on each plan card relative to the org's current tier. Upgrades go through Stripe Checkout with immediate effect and a prorated charge; downgrades schedule for the next cycle. Switching billing interval (monthly to yearly or back) on the current tier reuses the upgrade flow. Enterprise is sales-only — the card opens a mailto rather than checkout.

The four-card grid mirrored from the public pricing page so operators can compare tiers in-product. Each card surfaces tier price, included quotas, surface coverage (Ledger / Registry / Shield), the overage rate that applies above-cap, and a CTA reflecting the action available from the current tier — Upgrade, Downgrade, Current plan, or Contact sales for Enterprise. Highlighted cards mark the recommended tier; the current tier carries a "Current plan" pill at the top so it's unmistakable.

The Wytness subscription tier currently active on this organisation. Each tier sets the included event quota, agent cap, retention window, and which surfaces (Ledger, Registry, Shield) are available. Operators upgrade when consistent overage makes the next tier cheaper than pay-as-you-go; auditors check the tier against the retention obligation in the customer's compliance regime.

The Azure Blob container that holds events Wytness refused to chain into the authoritative archive — envelope signature failures, unregistered key IDs, malformed wrappers, and integrity-flagged sequences. These events stay searchable and recoverable but never count toward billing or chain hashes, so a downstream investigation can see what was rejected without trusting the rejected payload. The admin Poison Events panel is the customer-facing surface; the container itself is named `wytness-poison` in your storage account, alongside the archive container.

A Shield policy is a named rule that pairs a selector (which agent actions match) with a decision (allow, queue, or block) and a mode (observe or enforce). Operators author policies to encode guardrails: "queue any refund over $500", "block tool calls from unapproved agents", etc. Auditors review the policy list to confirm that documented controls have a matching policy and that high-risk decisions sit in enforce mode.

The author surface for a single Shield policy. Operators pick a name, build a selector that matches the agent actions they care about, set the decision (allow, queue, or block), and choose a priority that orders this rule against other policies that may also match. New policies always start in observe mode so the team can watch the decision land in the log before flipping the policy to enforce. Auditors look at the editor's saved state — name, selector, decision, priority, mode, enabled — as the canonical record of what the control intercepts and how.

The per-source marker recording how far through the source log this collector has read, persisted to the container's volume so a restart resumes instead of starting over. Each poll deliberately re-reads a short overlap behind the cursor and lets deduplication discard what it has already shipped, because event identity is derived from the source row rather than from the clock — so the same row collected twice collapses to one event. An operator only needs to care when the volume is lost: the worst case is re-work, never a gap or a duplicate in the record.

The recompute side of the Crypto section's previous-event linkage — what Wytness derives from the prior event's content versus what the prior event actually stored. A mismatch between recompute and stored value is one possible source of an AGT hash-chain verdict break. Click to copy the full hash for chain-break investigation.

The AGT entry hash of the event immediately preceding this one in the customer's audit chain. Storing the previous hash inside each event is how AGT achieves tamper-evidence: an attacker rewriting an old event invalidates every subsequent Previous hash. Auditors verify this field links cleanly to the prior event's Entry hash; a mismatch is a chain break.

Which rate the cost figure on this row was computed from, shown so no dollar amount is ever unattributed. An operator checking an unexpected estimate starts here: a list-price row prices at the vendor's published rate, and a "your rate" row prices at what you entered instead. "No price on file" is deliberately not an estimate — a model with no known rate keeps its token counts and shows no cost.

Integer priority that orders policy evaluation when two or more policies match the same agent action. Lower values win — priority `10` evaluates before priority `100`. Operators use this to sequence overlapping rules (e.g. a broad allow-list with a narrower block-list that needs to win). Auditors check that escalating-risk policies sit at lower priority numbers so they intercept before any broader allow rule.

A first-4-and-last-4-character snippet of the private key stored alongside the public key so the operator can confirm which private half they hold without exposing the full secret. Wytness never receives or stores the full private key — only this hint plus the corresponding public key. Use the hint to disambiguate when you have several environments holding different private keys for the same scope (e.g. comparing the hint shown here against the value in your secrets manager). If the hint doesn't match what you have on disk, you're holding the wrong key.

The prompt or message that triggered the agent's action — captured verbatim from the SDK call site. PII inside the prompt is tokenised at the customer edge before the event is signed; revealed values are only visible when the operator unlocks them with the browser-resident key. Foundry agents in `payload_mode=metadata_only` strip the prompt at ingest and render `[redacted, PII metadata-only mode]` here.

How a mid-cycle plan change settles against the current billing period. Upgrades are immediate: the new tier's quotas activate at once, the new monthly rate prorates for the days remaining in the cycle, and Stripe charges the delta as a one-off invoice line. Downgrades schedule for the next cycle so the customer keeps the period they've already paid for — no refund for the unused portion of the higher tier. Switching billing interval (monthly to yearly) is treated as an upgrade and prorates immediately; the reverse is treated as a downgrade and waits for the cycle boundary.

AGT 4.0 structured metadata describing the protocol-level shape of the event — framework adapter, MCP server name (where applicable), shield adapter decisions. Surfaced verbatim from AGT; cross-checked against AGT's own audit verifier when present. Optional — older AGT versions don't emit this.

Where this event came from and which signing path attested to it. An operator checks Provenance to know whether the event entered the audit trail through AGT's native chain, the Wytness wrapper envelope, or an explicit operator correction. An auditor verifies that Provenance is non-null across the period under review — null values mean the event predates the cutover and may not carry per-event non-repudiation.

The downstream system this connector pushes to. Each provider has its own wire format, authentication style, and configuration fields; pick the provider that matches the team that will consume the alerts. Connectors are a Business-and-above feature — Business and Enterprise see all five providers; Starter and Growth have no connector access.

The prefixed identifier that stands in for a PII value in stored events — e.g. `EMAIL_a59fc578` — produced by HMAC-ing the raw value with the customer-held secret, so the same value under the same secret always yields the same token across every session and agent. One value can legitimately carry two tokens: the detected-type prefix (`EMAIL_`, `PHONE_`, …) and the declared-field `PII_` prefix, which is why Subject lookup searches both in one pass. Auditors treat the token as the subject's stable identifier inside the trail: lookups match by token, and an Article 17 redaction run targets the token, not the raw value. Rotating the HMAC secret starts a new token lineage — events before and after rotation carry different tokens for the same person.

A short derived identifier of the public key (typically a base64-prefixed truncation of the SHA-256 over the raw key bytes), used by the ingest path to look up which registered key should verify a given event's envelope. The wrapper emits the fingerprint as the envelope's `key_id` on every event; Wytness resolves it back to the matching public key. Operators use the fingerprint shown in the table to confirm a wrapper is signing with the key they think it is; auditors trace fingerprints from event detail panels back to the Keys page to confirm the verifier had the right material at ingest time.

The agent's free-text rationale for choosing this tool and these parameters — the chain-of-thought summary the SDK captured at decision time. Empty when the agent runtime doesn't surface reasoning or when the SDK is configured to drop it. Auditors weight this as a hint, not evidence: agent reasoning text is not a structured audit field and can be hallucinated, but inconsistencies between reasoning and parameters are still useful signal.

The eight most recent anomaly alerts, regardless of the active window — chosen so a quiet day still surfaces the last few signals worth knowing about. Each row carries a severity badge, plain-language description, the agent that triggered it, and a timestamp. Click any row to deep-link into Anomalies with that alert pre-selected. An empty list with the "All agents operating normally" message is the healthy posture.

Count of the most recent audit events that carry this permission, capped at fifty rows for the preview list on the Events tab. The full retention is not truncated — the "Open all matching events" button on the Events tab routes to the global Events page pre-filtered by permission for unbounded paging. Operators use the preview to spot the latest exercise of a scope at a glance; deep-dives jump to the global Events page where the full filter and search surface is available.

The EU AI Act register export — a PDF listing every registered agent with its risk classification, approval status, assigned operator, and current event volume. Generated on demand from the Registry page action; the document an external auditor reads to confirm that the operator maintains the technical inventory required by Article 11. Operators regenerate before each audit cycle so the snapshot reflects the period under review.

Re-runs a recorded session's inputs against the agent's current configuration and compares the new outputs against the golden trace. The use case is regression catching: if you tweaked a prompt, swapped a model, added a tool, or revised a policy, replay tells you whether the agent still handles the canonical exchange correctly. The Replay button stays disabled until both (a) a golden trace is set for the agent and (b) the backend replay engine is wired (currently in progress) — per the honest empty-state contract, no fake action is ever shipped.

What the tool returned to the agent — payload, status, error, or whatever the SDK captured. Same PII handling as Prompt and Parameters: tokenised at the customer edge, revealed only with the browser-resident key. Foundry agents in `payload_mode=metadata_only` strip the response at ingest. Auditors compare Response against the documented tool contract and look for unexpected data classifications.

The minimum number of years that audit blobs must remain readable and unmodifiable in your archive container. SOC 2 typically expects three years of retained evidence; the EU AI Act Annex IV requires ten years for high-risk systems; financial-services regimes (SOX, MiFID II, ASIC) commonly require seven. Wytness recommends seven years as a defensible default that covers most operators without forcing a regime-specific decision. The retention window is enforced by the immutability policy on your archive container — it is not a Wytness setting. Until WORM-Option-A surfaces a retention picker in this page, the seven-year recommendation lives in the wizard's prerequisites copy only.

How many times the agent retried this tool call before the final outcome — captured by the SDK from the framework's retry middleware. A non-zero value paired with a `success` status means the tool succeeded after transient errors; paired with `failure` it means the configured retry budget was exhausted. Operators tracking flakiness watch the per-tool retry distribution on the Tools page.

The schedule on which Wytness re-attempts a failed delivery before giving up. Each subsequent attempt waits longer than the last (exponential backoff with jitter), capped at a configurable maximum number of attempts. The goal is to ride out transient downstream blips without burying a permanently broken endpoint in repeated failed POSTs. Operators check the delivery log to see where in the retry sequence a row sits; auditors verify the configured cap is consistent with the downstream system's published SLA.

The auditable feedback log AGT's RewardEngine maintains for an agent — every reward signal (positive or negative) the agent has received, broken down by dimension. Reward signals are the input data feeding TrustManager's Bayesian score update, so this is the "why did the trust score change?" panel. Customers can extend the dimension set with their own canonical labels; the four AGT-shipped dimensions are the defaults. A long tail of negative rewards on one dimension is the early signal of a training-data or capability mismatch worth investigating before TrustManager catches up.

AGT 4.0's RingEnforcer assigns every agent a concentric privilege ring (0 = core, 3 = sandboxed) that bounds which tools it may invoke. Shield policies layer per-action decisions on top of the ring's coarse allow/deny lists. Operators use the Ring panel to see which agents sit in which tier and how many breaches the enforcer has caught. Auditors check that high-risk agents sit at higher ring numbers (more constrained) and that breach counts are low.

The EU AI Act risk tier assigned to this agent by the operator on the Registry page. Operators classify each new agent so the evidence pack auditor knows which transparency / conformity obligations apply. Auditors verify that every production agent has a non-`unclassified` tier and that high-risk agents have documented conformity assessments.

The written rationale required when classifying an agent as High or Prohibited under the EU AI Act. The Classify dialog blocks Save until a justification is entered for these tiers; the text is sealed into the signed audit entry alongside the new classification. Auditors require this document for every high-risk agent — it is the operator-side evidence that the tier was set deliberately, with reasoning, not by default.

Rogue-behaviour severity for the agent at the time of this anomaly. The live producer is Wytness's capability-deviation rule (`capability_profile` — the agent used actions outside its declared capability set); the other strategy values (`resource`, `sequential`, `statistical`) appear only on historical rows. The chip surfaces severity; hover for the strategy. Operators record a kill decision for agents that go `critical`; auditors verify the agent's capability profile is documented and that rogue events were triaged.

How many rows this source returned on the collector's most recent poll. It is a liveness reading rather than a total — a zero here is normal for a quiet hour and only matters once the source crosses its silence window. An auditor uses it alongside the last-row time to distinguish a source that is being polled and has nothing to say from one that has stopped being polled at all.

Which anomaly detector fired. A background detector evaluates these seven independent rules every five minutes against your agents' events; when a rule fires, an alert lands here. Operators learn the rule names quickly because each one points to a specific kind of investigation (chain break → Verify; restricted_data → permission review; etc.). Auditors map rule firings to control-effectiveness evidence — repeated `high_error_rate` fires on the same agent indicate the underlying control is not working.

The action that re-runs chain verification on demand against the live event store — recomputes every Merkle link, re-checks every Wytness envelope signature, and stamps `last_verified_at` on the agent record. Operators click this when a new break was triaged or before generating an evidence pack. Re-verification cannot silently downgrade a `Resolved tampering` badge back to green — the operator's documented triage is preserved across runs.

The opaque identifier of the scope token the agent presented when it performed this action. A scope token bundles the permissions in effect plus the principal that issued them; it's the credential the agent used at this exact moment. Auditors trace a token back to its issuance event in the agent identity registry to confirm the agent was authorised at the time it acted.

The downloadable JSON form of this Evidence Pack, wrapped and signed by the platform so the file itself carries proof it left Wytness unaltered. It holds the same content as the pack on screen, plus the material a third party needs to check it: untruncated per-event signatures, the published public keys, and the exact signed bytes where those were retained. The fingerprint that sealed it is published on the public Trust page — an auditor must compare against that published value, because a key the document supplies about itself proves nothing.

Free-text substring match applied server-side across event id, agent id, tool name, reasoning summary, prompt, response, hashes, and permission names — the row count and charts follow the narrowed set. Pasting a UUID routes directly: tool ids open the tool page, agent GUIDs swap in an agent filter. Auditors use it to pull every event that touched a named resource before exporting the filtered evidence set.

The JSON DSL Shield uses to match agent actions. A selector is a tree of predicates joined by `and` / `or` / `not` combinators; each leaf predicate compares a field (e.g. `tool_name`, `inputs.amount`, `agent_id`) to a value using one of ten operators (`eq`, `ne`, `gt`, `lt`, `gte`, `lte`, `in`, `nin`, `matches`, `exists`). The guided builder on the policy editor covers the common flat-AND/OR shape; raw JSON editing is available for nested trees. Auditors review selectors alongside their decisions as the canonical record of what the control actually intercepts.

Which ServiceNow API the connector writes to — the Incident table (default) or ITOM Event Management. The Incident table works out of the box on any ServiceNow instance — it raises an incident record an analyst can triage in the usual queue. ITOM Event Management is a separate paid module that correlates events into alerts and CIs; pick it only if your operations team already runs on Event Management. Authentication is basic-auth in both cases (username plus password, stored encrypted server-side); your ServiceNow admin should provision a dedicated integration user with the narrowest write role that the chosen API needs.

The conversation or workflow session this event belongs to, as reported by the SDK. Distinct from the table's combined "Session / Trace" column — that column prefers the AGT trace ID when present and falls back to this field for legacy rows. Use it to group every event from a single chat thread or batch job for forensic walks.

The conversation thread (session) or distributed-trace ID this event belongs to. Sessions group all events between the user opening and closing a conversation; trace IDs follow a single request as it hops across agents and tools. Click to open the Sessions page filtered to this trace and see the full event timeline in order.

Wall-clock span between the session's first and last event timestamps, surfaced as a pill in the detail header. Rendered as milliseconds for sub-second sessions, seconds for under a minute, minutes otherwise. Operators use duration to gauge interactive sessions (seconds) vs long-running automations (minutes / hours). Auditors check duration against the expected upper bound for an agent's risk tier — multi-hour sessions on a high-risk agent often warrant a manual review.

How loud this alert should be. Each anomaly rule emits one of four severities, which drive both the row colour and the notification fanout — critical and high page the on-call rota (if a connector is configured), medium and low stay dashboard-only. Operators triage critical and high first; auditors verify that no critical anomaly went un-acknowledged for longer than the SLA window.

Fraction of tool invocations covered by an explicit Shield policy — i.e. an invocation matched a deny / allow / approval rule rather than falling through to the org default. The KPI tile currently renders an em-dash with "Shield not yet enabled" until your org turns Shield on; once enabled, the value rises as you author policies. Operators use it as the headline Shield maturity metric; auditors expect a stated target for production (commonly ≥ 80% by launch + 30 days) and evidence of progress against it.

The per-event Ed25519 attestation Wytness adds on top of AGT's hash chain — every wrapper-mode event is signed at the customer edge with the customer-held private key before it leaves the runtime, and the public key registered on Wytness verifies the signature at the ingest boundary. Operators check the Wytness envelope attestation panel in the pack to confirm the verified percentage is at or near 100; auditors treat the signed envelope as the non-repudiation primitive — the agent owner cannot later deny having attested to a specific action without invalidating the signature.

The exact bytes an event's Ed25519 signature was made over, retained alongside the event so the signature can be checked again later. Without it a stored signature is unverifiable in principle — the record kept afterwards is a mapped projection of the original message, not the message — so retaining it is what turns a recorded verdict into evidence anyone can re-derive. Erasure under a right-to-erasure request clears the payload while keeping the signature, which is why an erased event reports that it can no longer be independently verified.

Which cryptographic algorithm Wytness used to sign and re-verify the per-event envelope. Currently `Ed25519` across the entire fleet — a fast, standards-compliant elliptic-curve signature scheme. Pinned to a single algorithm so verification logic stays single-purpose; algorithm agility would have to roll out through a coordinated SDK + ingest upgrade.

Whether Wytness holds the agent's public signing key and can independently verify each event's per-event Ed25519 envelope. `absent` is the strongest gap signal — the agent's events have no non-repudiation. The scope chip beside the icon distinguishes agent-specific keys (stronger compromise containment) from the org-wide fallback (shared across all unkeyed agents).

A dry-run that replays a policy's selector across the last N days of audit events and reports how many matched + which decision the policy would have made. Nothing is written; no agent action is intercepted; the simulator only inspects history. Operators run the simulator before flipping a policy from observe to enforce to confirm the match rate matches intent (too many matches = selector too broad; zero matches = selector wrong). Auditors treat simulator results as evidence the operator reviewed the policy's blast radius before enforcement.

Provenance for the skill or tool implementation the agent invoked — the skill's name, where it came from (a registry, a package, or inline code), whether its metadata came from a source the AGT kernel trusts, and content hashes of the agent's context captured immediately before and after the invocation. Recorded by AGT since its 4.1/5.0 release train; on TypeScript runtimes the block is covered by AGT's tamper-evident entry hash, so it cannot be altered after the fact. Review it for supply-chain questions: which implementation actually ran, and did the invocation change the agent's context. Empty when the agent's AGT runtime predates the feature or the framework adapter emitted no skill metadata.

The Slack connector posts a formatted message to a single Slack channel via an Incoming Webhook URL. The URL itself is the secret — anyone who holds it can post to that channel — so it is stored encrypted server-side and never displayed back in plaintext. Configuration is one field: paste the webhook URL from the Slack app's "Incoming Webhooks" feature. Auditors verify that the webhook is scoped to the smallest channel that the responder team actually watches and that it is rotated when team membership changes.

One logging store this collector polls, shown by its kind and optional display name. Each source is configured with its own workspace and credentials in the container's environment, and only nine non-secret descriptor fields are ever persisted server-side, so a credential cannot reach the platform even if one were posted. An auditor treats each source as a distinct capture channel with its own evidence of continuity.

The most recent error this source hit while being polled, reported with the heartbeat and truncated for storage. One source failing does not stop the others in the cycle, so an error here narrows the problem to a single workspace or credential rather than the collector as a whole. An operator pairs it with the source status: an error plus a silent badge means capture for that channel has actually stopped, and the gap will need explaining.

The wire-level shape the SDK used to send this event to the Wytness ingest endpoint. Wrapper-mode formats carry the Wytness per-event envelope (non-repudiation); direct CloudEvents carry only the AGT chain. Auditors compare format distribution to confirm that production traffic is on the wrapper path, where customer-held keys provide independent attestation.

The wire-level shape this event was received in — SDK type, version, content-type, and (for wrapper formats) envelope version. Operators use this to debug ingest issues; auditors check that production traffic is on the wrapper path with a current SDK and envelope version.

Which product's telemetry this source reads, which decides how much of each interaction is available to capture. The two kinds differ in depth rather than trust: Foundry exposes the full model context, while Copilot Studio exposes only what crosses the agent boundary. An auditor needs the kind to know what a gap in the record means — an absent system prompt on a Copilot Studio event is a limit of the source, not a missing entry.

Whether this source is still producing rows, judged against a silence window that defaults to six hours and can be set per source. The judgement is made server-side from the timestamps the collector reports, so the app and the admin console can never disagree about it, and a source that has never produced a row counts as silent from the moment its collector was first seen. An auditor reads a silent source as a gap that needs explaining — capture stopping quietly is the failure mode a log-based tier has to make visible.

The OpenTelemetry-style span identifier for this event within its enclosing trace. The trace ID groups every event from a single request; the span ID identifies one operation inside that trace. Operators walking a multi-step agent decision follow the parent-span hierarchy to reconstruct the call graph. Standard 16-character hex.

The agent's SPIFFE workload identity, expressed as a SPIFFE Verifiable Identity Document (SVID) URI such as `spiffe://acme.corp/ns/prod/sa/billing-agent`. SPIFFE is a CNCF-maintained standard for assigning short-lived, cryptographic identities to software workloads — mostly used inside Kubernetes-based platforms running SPIRE for issuance. Wytness surfaces the SPIFFE ID on AgentDetail only when the AGT runtime has registered one; the row is hidden entirely for agents that don't run in a SPIFFE-aware fleet (no em-dash, since SPIFFE is workload-specific not universal). Source: `agentmesh.SPIFFEIdentity` in AGT 3.7.0+.

The Splunk connector posts to the HTTP Event Collector (HEC), which is the standard ingestion endpoint for both Splunk Cloud (port 443) and self-hosted Splunk Enterprise (port 8088). Configuration takes the full HEC URL, the HEC token (sent as `Authorization: Splunk &lt;token&gt;`), and two optional fields — sourcetype and index — that override the HEC token's defaults if your Splunk admin wants events filed into a specific index or under a specific sourcetype. The token is stored encrypted server-side. Auditors verify that the HEC token has a narrow allowed-indexes list and is rotated on a defensible cadence.

The outcome of the tool invocation. One of six canonical values locked by `docs/facts/event-status-semantics.md`. Used to compute the per-agent error rate, filter rows on this page, and tint rows when the value is `blocked` or `denied`. Auditors review the distribution to spot regressions, upstream service issues, policy interceptions, and HITL denial patterns. The full visual treatment (badge tones, row-tint rules) lives in [event-status-breakdown](event-status-breakdown.md).

Donut chart of this tool's invocations broken down by terminal status — `success`, `error`, `blocked`, `timeout`. Operators use it as a finer view than the headline Success rate KPI: a tool can sit at 95% success on paper while quietly accumulating `blocked` and `timeout` slices that hint at policy friction or upstream slowness. Auditors compare the distribution against the tool's documented expected-failure profile (e.g. a tool that legitimately blocks 10% of calls reads very differently to one that's silently timing out the same 10%).

The fully qualified Azure Blob endpoint for your storage account, in the form `https://youraccount.blob.core.windows.net`. Found in the Azure Portal under Storage Account → Endpoints → Primary endpoint → Blob service. Wytness combines this URL with the directory (tenant) ID and the service principal credentials you supply to authenticate writes via the Azure SDK; the URL alone is not sensitive (it identifies the account but does not grant access). Wytness does not store an Azure connection string in the classic key-and-secret format — the service principal model is preferred because it scopes blast radius to the SPN and lets you revoke access without rotating an account key.

Whether your private storage has been activated as the destination for new audit events. The wizard concludes by requiring you to type ACTIVATE — once accepted, the ingest path immediately switches from Wytness shared ClickHouse + Blob to your supplied endpoints. There is no "deactivate" button by design: rolling back would either drop events (unacceptable for audit) or run dual-write (fragile). Contacting support is the documented path if you need to reverse, so the operations team can plan an orderly migration of any new events back into shared storage.

A periodic probe Wytness runs against your storage endpoints to confirm reachability and write permissions. The probe writes a single small sentinel blob into the archive container and runs a `SELECT 1` against ClickHouse, returning the timestamp of the last successful round-trip. An unhealthy result means new events may queue or be deferred — investigate the underlying credential, network, or storage-account state before drift accumulates. The probe interval defaults to 5 minutes and runs server-side; the displayed Last check timestamp is the most recent probe success or failure.

A previously-configured endpoint whose provider is no longer available on your current plan. The endpoint keeps its configuration, but its provider tab is hidden, so it can be deleted — not edited — until the plan covers that provider again, and Wytness will not dispatch to it in the meantime. The banner above the connector table lists every stranded endpoint with an inline Delete affordance; alternatively, upgrade your plan to re-include that provider and the endpoint resumes dispatching automatically.

The colour-coded chip showing which ingest stream carried this event — Wytness wrapper (Python or TypeScript) vs direct AGT CloudEvents. Same vocabulary as the table's Src column for visual continuity. Wrapper streams carry the per-event Ed25519 envelope; direct AGT streams carry only the AGT hash chain. Use this to spot at-a-glance whether the event has full non-repudiation coverage.

The lifecycle state of the organisation's Wytness subscription. The badge in the current-plan summary card reflects whichever state the billing system reports — trial, paying, or stopped. Operators upgrade out of `expired` / `trialing` before ingest is rejected; auditors confirm the org was `active` across every period in the evidence pack.

Fraction of this tool's invocations that completed with `status = success` within the active page window. The detail page renders it as a percentage to one decimal (e.g. `95.0%`). When no invocations have been recorded yet, the backend returns a sentinel `-1` and the cell displays an em-dash so the empty signal is unambiguous. Operators use Success rate as the first triage signal — a drop below the historical floor usually beats every other KPI to the punch on incident timelines. Auditors look at long-window success rates as a baseline for reliability claims in evidence packs.

A bounded duration over which Wytness mutes future fires of this rule on this agent. Suppressions exist so a known noisy rule doesn't drown the inbox during a planned event (rollout, batch job, scheduled maintenance), but the windows are capped so a typo can't mute the alert forever. Operators include a reason on every suppression; auditors verify that the reason is recorded and that long suppressions (≥ 7 days) were approved by a second pair of eyes.

The canonical product term for the root cause of a chain break — either a Wytness envelope signature failure (the strongest cryptographic tampering signal) or an AGT Merkle chain-link mismatch (a softer signal that requires operator review). Operators triage every flagged break through this lens; auditors require an explicit resolution (approved / agt_chain_restart / false_positive / other) for each one before the verification report clears back to Verified.

The customer-supplied task identifier the agent was working on when it emitted this event. Set on the SDK side via the `task_id` argument or environment variable; opaque to Wytness. Useful for stitching events across multi-step jobs or correlating with the customer's own work-queue system. Empty when the SDK doesn't supply one.

Page-level time range that scopes the table's per-agent metrics (Total events / Errors / Error rate). Chain integrity columns are sticky across windows — a chain break is a chain break regardless of the time selector. Operators flip this for trend triage; auditors typically select "All" for evidence pack period coverage.

A 7&times;24 grid of invocation counts bucketed by day-of-week and hour-of-day in your local timezone (set in user preferences). Darker cells are busier. Operators use it to spot off-hours invocations that might indicate a leaked credential, a scheduled job that ran twice, or a runtime running outside the expected operational window. Auditors compare actual usage rhythm against the documented "intended operating hours" claim in evidence packs. When the page Window selector is set to "All time" the heatmap falls back to a 30-day window so the grid stays statistically meaningful — multi-year retention would smear interesting patterns into uniform shading.

When the event was emitted by the agent runtime, in the viewer's local timezone. Stored as UTC at millisecond precision; rendered relative for recent events and absolute for older ones. Auditors verify that timestamps are monotonic per agent — out-of-order timestamps within a chain are a tampering signal.

The tool or capability the agent invoked when this event was emitted — typically the name of a function decorated with `@audit_tool` in the agent code (e.g. `query_database`, `send_email`). Tools are the granular unit of agent action; auditors trace which tools an agent uses to identify the privileged operations that need higher scrutiny.

Collapsible card inside a conversation group that surfaces one tool invocation — the tool name, its provenance badge, status, and duration. Click to expand and see the parameters, reasoning summary, error code (if any), and the event ID for cross-reference into the Events table. Parameters stay tokenised until the operator unlocks the Reveal toggle. Bubbles are the granular unit of "what the agent actually did" — auditors walk these in order to attribute every privileged operation to a specific tool call.

How tool identity is computed and deduplicated within your org. The natural key is the tool **name** the AGT runtime captured (forwarded by the `wytness` wrapper or direct AGT ingest); two agents calling `refund_customer` collapse to one row with two callers. A short stable UUID is also assigned per tool — the name is the canonical handle, the UUID is the durable handle used in cross-surface paste-search. If your code ships two genuinely different implementations under the same name they collapse into one row here; the Activity tab will reveal the divergence via different inputs/outputs and the fix is on your side (namespace the names). Operators use this to understand why a row's metrics look bimodal; auditors verify that production tools have unambiguous names so evidence is traceable to a single implementation.

Calls per hour for each tool this agent has invoked over the rolling activity window, computed by AGT's ToolCallFrequencyAnalyzer. The triage view for "what is this agent actually doing right now?" — sorted noisiest first so the dominant calls are obvious. Pairs naturally with the per-agent BehaviorBaseline: a tool whose rate has jumped 5× over its baseline mean is the early signal of a frequency-spike anomaly worth investigating before the rule fires formally. Customers also use this to size rate-limit policies — eyeballing the busiest agents' tool rates is faster than parsing event logs.

Horizontal bar chart of the agents that emitted the most events in the current window. Bar colour layers a health signal on top of activity: indigo for healthy (error rate at or below 1%), amber for elevated (1-10%), red for high (over 10%). A red bar at the top of the chart is the prime triage target — high volume amplifies the impact of a bad error rate. Click "View all" to land on Agents pre-filtered to the active window.

Lifetime count of audit events emitted by this agent within the active time window (set by the page-level Window selector). Useful as a rough activity gauge — operators sort by this column to find the loudest agents. Auditors compare event volumes against expected baselines to spot anomalous activity bursts.

The AGT distributed-trace identifier — propagated through every agent and tool involved in a single request hop chain. Pasting a trace ID here surfaces every event that shares it, across agents and sessions. Auditors use it to walk multi-agent decisions end-to-end without losing causality.

The UTC timestamp at which the 14-day free trial expires. Up until that moment the org has trial-level access to its picked tier; ingest accepts events up to the plan cap and rejects with 402 above. After the trial ends Wytness gives a 7-day grace window — during grace the trial behaviour persists, after grace the org auto-upgrades to the picked tier if a card is on file, or moves to `expired` and stops accepting events if it isn't. Operators add a card before the countdown hits zero to avoid a service gap.

AGT 4.0 cumulative trust signal — a Bayesian estimate of how reliably this agent has performed historically, surfaced as a 0-100 score. Updates with every event; high scores mean the agent has a long track record of low-error, low-risk behaviour. Distinct from the operator-set EU AI Act Risk classification on Registry: Trust is computed from the agent's recorded history, the classification is a regulatory tier a person assigns.

The three-state trust taxonomy the Verify page renders against an agent's chain. Verified is the only state that proves nothing has been altered; Tampering detected is the cryptographic certainty signal; Verification pending is the honest "we need a human" state that does NOT accuse the data of tampering on its own. Operators triage `not_yet_checked` events against their deployment timeline; auditors require `verified` across the entire evidence period.

The cryptographic artefact set rendered in section 7 of the pack — AGT Merkle hash anchors (first and last event hashes for the period), the Wytness envelope verdict summary, the source-format breakdown (wrapper vs direct AGT), and the layered security model. Operators glance at the verdict summary to confirm chain integrity and envelope coverage are within tolerance; auditors recompute or spot-check anchors against the published API to verify the pack hasn't been altered between generation and review.

The per-agent record of a chain verification run — what was checked, when, and the outcome across all three integrity layers (AGT Merkle hash chain, AGT identity, Wytness envelope). Operators trigger one by clicking "Run verification"; the line chart aggregates pct-verified across all agents over the active window. Auditors download the signed PDF export of a verification report as evidence that the chain was independently re-checked during their period of review.

The time window that scopes the verification history chart, the breaks-by-time-period bar chart, and the "Chains verified" KPI. The Verify page accepts up to 90 days (wider than the shared 24h/7d/30d/all window used elsewhere) because chain integrity is investigated retrospectively. Operators widen the window during incident triage; auditors typically pick the longest range that covers their evidence period.

The per-agent verdict rendered on each verification card — the outcome of the most recent `/verify` call combined with the resolution status of any historical breaks. Six derived states cover the full lifecycle from a freshly registered agent through resolved tampering. Operators glance at the verdict pill to triage; auditors verify that every production agent is in `Valid` or `All Resolved` for the evidence period.

Every AGT `AuditEntry` or `GovernanceEvent` that persists into the audit trail counts as one billed event, regardless of payload size or framework. The Wytness wrapper forwards them automatically; direct AGT CloudEvents POSTs are counted the same way. Envelope-rejected events (unregistered signing key, bad signature, malformed wrapper) never reach storage and are not billed — only persisted events appear in the cycle counter. Auditors confirm the billing total reconciles with the count of stored audit rows for the same period.

Diagnostic metadata captured at ingest — correlation ID, request size, the originating IP, and the ingest path the request hit. Used to reconstruct request flow during incident investigation. Not load-bearing for compliance evidence; can be skipped by reviewers.

Write Once, Read Many. A storage-level immutability policy that prevents any actor — including the storage-account owner — from modifying or deleting a blob until the retention window expires. Wytness recommends a seven-year immutability policy on the archive container so the audit trail survives subpoena, incident, and operator turnover without anyone being able to retroactively edit history. WORM is configured at the container level on your Azure storage account (Configuration → Immutability policy → Time-based retention); Wytness writes into the container but does not control the policy itself, by design — the customer holds the only knob that could weaken it. Auditors look for a policy in `Locked` state, not `Unlocked` (an unlocked policy can be shortened by the owner).

Which Wytness wrapper SDK posted this event — "TypeScript (wytness-ai)" or "Python (wytness-ai)". The label is a friendlier rendering of the `source_format` enum; same information as the Format and Stream fields, just spelled out for readers who don't memorise the enum codes. Both wrappers ship feature-parity (per-event Ed25519 signing, PII tokenisation, AGT chain forwarding).

The "agent owner attested, non-repudiation" verdict — re-verifies the per-event Ed25519 envelope the Wytness wrapper applied at signing time. The customer holds the private key in the browser or SDK environment; Wytness only sees the public half. A green verdict here is the strongest evidence Wytness can produce that the agent owner cannot later deny having performed this action.

The version of the Wytness wrapper SDK (`wytness-ai` Python or `@wytness/ai` TypeScript) that emitted the event. The wrapper layers per-event Ed25519 signing and customer-held PII tokenisation on top of the underlying AGT runtime. For pre-cutover rows the field falls back to the legacy `agent_version` string. Auditors verify a current SDK version across production traffic; older versions miss recent envelope and tokenisation fixes.