Agentic Observability

Overview

Canonical Agentic activity has four views:

1. Activity → Runs records every normal SDK workflow lifecycle and immutable topology snapshot.
2. Activity → Decisions records every workspace authorization decision and its integrity evidence.
3. Activity → Trends aggregates executions, verdicts, tools, identities, triggered controls, status, and latency for a selected time window.
4. Activity → Audit records recent relationship writes and deletes, including the operator, subject, relation, resource, and condition.

Optional OpenTelemetry/Langfuse export is asynchronous and can be sampled. The local execution and authorization ledgers are not optional telemetry: they remain workspace-scoped and are captured independently of export sampling.

Where to view Agentic activity

Surface	Use it for
Agentic → Activity → Runs	Open one workflow and inspect its topology, actors, roles, permissions, tools/actions, delegations, and per-check decisions.
Agentic → Activity → Decisions	Search/filter individual decisions, inspect check evidence, paginate at the server, and export the current filtered page as CSV.
Agentic → Activity → Trends	Review time-windowed execution, verdict, tool, identity, triggered-control, status, and latency trends.
Agentic → Activity → Audit	Inspect the latest 200 access changes in this workspace; search and action filters apply within that recent window.
Agentic → Agents → Shared assets → Workflow maps	Inspect the most recently discovered design-time topology and drift state.
Analytics → Agentic	Review agent decisions, governed tools, and execution telemetry alongside the other analytics dashboards. MCP tool-call telemetry is on Analytics → MCP.
Policy & Access → Advanced → Relationships → Changes	Inspect the OpenFGA relationship change feed.

Legacy Agentic Observability trace bookmarks redirect to Activity → Runs. The former Posture, Findings, In-Line Control, Service Graph, and score dashboards are not separate evidence sources. Their useful investigation paths are covered by clickable run evidence, agent drift/quarantine, Agents → Needs attention, Policy & Access approvals, Activity decisions, and Activity trends.

Captured 10 October 2026 with synthetic demonstration data.

Managed server-run evidence

For server-managed execution, open the agent’s Review → Runtime access → Server run for saved onboarding state and output. Needs attention → Run incidents includes failed and uncertain server jobs. A job waiting for identity, runtime compatibility, or registration approval has not necessarily started a governed workflow, so it may not have an Activity run yet. Once execution starts, use Activity → Runs and Decisions for runtime evidence. Resolve Check run outcome before any replacement run; terminal jobs are not automatically replayed.

Execution detail

The SDK starts an execution at the framework boundary, associates governed decisions with it, and closes it as complete, blocked, failed, cancelled, or awaiting approval.

Open a run to inspect:

• Topology snapshot: agents, tools, named actions, and graph edges captured from the workflow that actually ran.
• Topology integrity: verification that the submitted topology matches the immutable recorded snapshot.
• Actor identity: the Virtual-Key-bound agent and optional acting user or service account.
• Authorization graph: the relevant relationship closure through groups, roles, permissions, resources, tools/actions, and delegations.
• Decision edges: the allowed/denied result of acts_for, permission, can_use, can_execute, and context checks.
• Decision evidence: verdict, reason, failed check, action, argument protection, and integrity-chain status.

Nodes and edges are clickable. Large decision sets use bounded server pages and show when the current graph contains only one evidence page; use the pager to inspect every step.

Discovery and execution are different

Agents → Shared assets → Workflow maps is the latest discovered design-time workflow. Activity → Runs is the immutable snapshot and authorization evidence for one concrete run. A discovered tool is not automatically authorized.

Decisions

Agentic → Activity → Decisions reads the canonical decision ledger rather than a generic LLM request log.

Use its server-side filters for:

• time range;
• search text;
• verdict;
• agent or acting identity;
• tool and named action;
• permission/object;
• failed check.

Opening a row shows the request identity, verdict/reason, every authorization check, linked run, and a plain-language integrity status. CSV export contains the current server-filtered evidence page; pagination and totals are explicit.

Tool arguments are bound to the decision with a cryptographic digest rather than the raw payload. The normal UI reports that protection without displaying the digest. The gateway does not put workload tokens, Virtual Key bearers, or raw tool arguments into the decision record.

Investigate a blocked run

1. Open Agentic → Agents → Needs attention and select the blocked run or outstanding registration. Check whether the outstanding item is identity proof, code capture, an action approval, or an access requirement.
2. Open Activity → Runs, select the execution, and inspect its decisions. Follow the failed check to the relevant identity, tool/action, resource, or delegation. A registration or code-capture failure can occur before a run is recorded; use its Agents → Needs attention review when no execution exists yet.
3. Use Activity → Decisions to inspect the exact verdict and reason. An action approval applies to its recorded request; it does not grant missing object permissions or prove workload identity.
4. After changing access, open Activity → Audit and confirm the recorded relationship change. Rerun the workload and inspect the new execution and decision. Earlier evidence remains associated with the earlier run.

Access-change audit

Open Agentic → Activity → Audit. Use Written or Deleted to filter relationship changes, or search for an actor, subject, relation, resource, or condition. Select Refresh after an access change.

The view loads the latest 200 changes. Its pagination and filters operate within that bounded window, so an empty search does not establish that an older change never happened. Runtime authorization outcomes remain in Decisions; provisioning jobs have their own Identities → Provisioning → Activity view.

Threat and compliance classification

Every decision on the enforced path is classified against the OWASP Agentic Top 10, which is what the NIST AI RMF, ISO 42001, EU AI Act, and MITRE ATLAS crosswalks resolve against. Classification maps the decision’s own reason code rather than matching on prose, so the category cannot drift as wording changes. An escalation the caller itself reported (fingerprint drift, recovery cost, or delegation chain) takes precedence, because it describes what happened rather than which check refused.

Verifying decision evidence

The decision ledger is append-only and hash-chained, and the append happens before the call proceeds: if the record cannot be written, the request fails rather than executing unrecorded.

Activity → Decisions reports integrity as a status. To re-verify independently:

curl -sS "https://gateway.example/api/agentic-new/decisions/verify" \
  -H "Authorization: Bearer $SESSION_TOKEN"

Key the chains in production with DEEPINTSHIELD_AUDIT_HMAC_KEY, and set the evidence retention period with DEEPINTSHIELD_AGENTIC_RETENTION_DAYS (default 730 days). See Evidence integrity and retention.

Trends

Agentic → Activity → Trends calculates exact server-side aggregates for the selected window instead of deriving totals from the visible table page.

The dashboard includes:

• executions, active runs, completion rate, and run duration;
• Allow, Deny, and Require-approval counts and decision latency;
• execution status distribution;
• top tools and named actions;
• top agents and acting users/service accounts;
• controls triggered (the checks that denied or escalated decisions);
• bucketed decision/execution timeline; and
• recent executions linked to their evidence.

Available windows range from one hour to 30 days. Refresh re-queries both aggregates and recent executions.

Backend-managed telemetry export

Telemetry destinations and credentials are deployment settings. They are not shown or editable in the Agentic workspace UI. The bundled local Docker stack starts Langfuse and connects the DeepIntShield backend automatically. Other deployments inject the collector settings through their secret manager.

Canonical execution and authorization evidence remains local and complete, whether or not an external exporter is configured.

Langfuse

Set the deployment endpoint:

DEEPINTSHIELD_LANGFUSE_ENDPOINT=http://langfuse-web.langfuse.svc.cluster.local:3000
DEEPINTSHIELD_LANGFUSE_PUBLIC_KEY=pk-lf-...
DEEPINTSHIELD_LANGFUSE_SECRET_KEY=sk-lf-...

The backend uses the same project keys for asynchronous OTLP export and read-only trace enrichment. Leave the endpoint unset to keep only the canonical local ledgers.

OpenTelemetry

Point optional fan-out at an OTLP/HTTP backend:

DEEPINTSHIELD_OTLP_ENDPOINT=https://otlp.example.com
DEEPINTSHIELD_OTLP_HEADERS=Authorization=Bearer-replace-me,X-Scope-OrgID=team

Store real credentials in the deployment secret manager rather than source control.

Performance and failure behavior

• Authorization stays synchronous and fail-closed.
• Workflow discovery, SIEM delivery, and optional trace export use bounded background paths.
• SIEM delivery is HMAC-signed over the exact bytes sent when DEEPINTSHIELD_SIEM_SIGNING_KEY is configured, with a timestamp inside the digest so a captured event cannot be replayed indefinitely. With no key the export is unsigned and otherwise unchanged; the local ledger is the source of record either way.
• Analytics uses server-side aggregates and bounded paging rather than loading an unbounded workspace history into the browser.
• Export failure cannot turn a Deny into an Allow or remove local authorization evidence.

Asynchronous export minimizes hot-path impact, while the synchronous authorization check, request-path instrumentation, and any cache miss retain measurable cost.

Privacy posture

For the strictest posture:

1. Leave external telemetry endpoints unset.
2. Keep sensitive-data redaction and tool-argument protection enabled.
3. Leave masked prompt preview disabled.
4. Review workload/Virtual Key logs for accidental application-side logging.
5. Use Activity → Decisions and Activity → Runs as the local evidence source.

The stored execution topology contains structure and canonical references, not raw prompts or tool arguments. The everyday UI resolves those references to friendly labels. The decision ledger contains protected argument bindings and authorization metadata.

Next steps

• Agentic Security: operate the Agents → Needs attention, agent inventory, Policy & Access, and Activity surfaces.
• Relationship Authorization - model roles, object access, tools/actions, and delegation.
• OpenTelemetry: configure collectors and vendor-neutral export.
• Built-in Observability: inspect LLM request telemetry outside the Agentic decision ledger.