AI Agent Runtime Risk & Action Governance Intelligence

Use this Actor to analyze ai runtime risk and action governance and return decision-ready structured signals. It is designed for repeatable human, API, Apify AI, and MCP-driven workflows.

Turn AI-agent execution traces into evidence-backed governance decisions.

This Actor analyzes what an autonomous agent actually did at runtime: tool calls, actions, permissions, approval state, sensitive-data access, side effects and behavior drift. It returns event-level risk findings plus an executive ALLOW / REVIEW / BLOCK decision that can feed security, observability, compliance and agent-control workflows.

Why use this Actor

Runtime behavior is the layer static security cannot prove.

Why this is different

Most agent-security scanners inspect repositories, prompts, MCP manifests or workflow configuration before execution. Those checks matter, but they cannot prove what happened after an agent started acting.

This Actor is built for the runtime layer. Supply agent events directly or point it at an Apify Dataset. It evaluates executed behavior against an optional policy and, when a previous snapshot is supplied, detects new permissions and changing risk patterns.

Key features

What it detects

• Unapproved high-impact actions such as financial, destructive, execution, deployment or privilege-changing side effects.
• Actions executed after approval was denied.
• Tool allowlist violations when a runtime call uses a tool outside the permitted set.
• Denied permission usage for explicitly forbidden scopes.
• Privilege creep when an agent starts using a new high-impact permission compared with the baseline period.
• Sensitive-data access when the supplied trace marks an event as containing or touching sensitive data.
• Runtime risk drift between current and previous execution snapshots.
• Concentrated agent risk through per-agent summaries, blocked/review counts and new permissions.

Input

Use currentItems for inline runtime events or currentDatasetId to analyze an Apify Dataset. A previous snapshot is optional through previousItems or previousDatasetId.

Useful event fields include:

{
  "eventId": "evt-103",
  "sessionId": "sess-44",
  "agent": "procurement-agent",
  "tool": "shell.exec",
  "action": "execute_command",
  "resource": "host:worker-2",
  "permission": "shell:execute",
  "approvalStatus": "denied",
  "sideEffect": "execution",
  "riskType": "privilege_escalation_attempt",
  "riskScore": 96,
  "sensitiveData": false,
  "timestamp": "2026-09-20T14:04:08Z"
}

Field aliases are normalized conservatively, so common variants such as toolName, agent_id, trace_id, approval_status, permissionScope and side_effect can also be used.

Optional policy controls

You can make the Actor evaluate traces against your own governance rules:

• allowedTools: exact tool allowlist. Calls outside it become findings.
• deniedPermissions: scopes that must never appear in executed events.
• requireApprovalFor: side-effect classes that require explicit approval.
• policy.thresholds.review: score at which an event becomes REVIEW.
• policy.thresholds.block: score at which an event becomes BLOCK.

The defaults are intentionally conservative for financial, destructive, privilege, credential, execution, deployment and external-write actions.

Output

One decision-ready report is written to the default Dataset and to the INTELLIGENCE_REPORT key-value-store record.

Core output includes:

• policyDecision: overall ALLOW, REVIEW or BLOCK.
• risk_score / agentRuntimeRiskScore: portfolio-level runtime risk.
• criticalCount, highCount, blockedActionCount, reviewActionCount.
• privilegeCreepCount, approvalViolationCount, sensitiveDataEventCount.
• runtimeDrift: baseline availability, risk delta and blocked-action delta.
• topViolationTypes: dominant governance failures.
• agentRiskSummary: per-agent event volume, max risk and new permissions.
• findings: evidence-backed event findings with remediation guidance.
• agentAction: machine-readable recommended next action.

Example finding:

{
  "eventId": "evt-103",
  "agent": "procurement-agent",
  "tool": "shell.exec",
  "permission": "shell:execute",
  "runtimeRiskScore": 100,
  "severity": "CRITICAL",
  "policyDecision": "BLOCK",
  "violations": ["ACTION_AFTER_DENIED_APPROVAL", "PRIVILEGE_CREEP"],
  "evidence": [
    "approval status is 'denied' for a high-impact action",
    "new high-impact permission versus baseline: 'shell:execute'"
  ],
  "remediation": [
    "Require an explicit approval token before the tool call can execute",
    "Reduce permission scope and bind elevated scopes to short-lived approval"
  ]
}

Use cases

Practical workflows

Agent observability

Feed traces from your orchestration layer on a schedule and monitor changes in blocked actions, sensitive-data access and privilege use.

MCP / tool-call governance

Normalize MCP calls into runtime events and use allowedTools, approval state and permission scopes to identify tools or actions that exceed policy.

Incident review

Run a suspicious session as currentItems to obtain a ranked, auditable set of findings and remediation actions.

Regression monitoring

Store each period as an Apify Dataset, then compare the latest period against a previous Dataset to detect risk and permission drift.

CI / release evidence

Run representative agent traces before and after a release. A rising risk score or new high-impact permission can become a release-review signal.

Security model

The Actor uses limited permissions and reads only the Dataset resources explicitly supplied to it. It does not require access to the rest of your Apify account. It does not execute submitted tool calls, scripts or commands; it analyzes trace records as data.

This is deliberate: a governance Actor should not become another privileged execution surface. Humanity has already invented enough of those.

Decision model

The engine combines explicit source risk scores, high-risk action terms, approval requirements, tool policy, denied scopes, sensitive-data markers and baseline permission drift. Multiple violations raise confidence in escalation without pretending that a heuristic score is a legal or security guarantee.

The result is deterministic for the same input and policy.

Pricing

Pay per event. One primary charge corresponds to one decision-ready intelligence report, not every trace row. This keeps recurring runtime governance economical even when the report summarizes many events.

Limitations

• The Actor analyzes supplied trace records; it does not intercept live agent traffic by itself.
• It is decision support, not a replacement for platform-level authorization, sandboxing or incident-response controls.
• Sensitive-data detection uses supplied flags and observable fields; it does not attempt exhaustive secret/PII discovery.
• Preserve stable identifiers across snapshots for the strongest drift analysis.

Suggested upstream sources

Any system that can emit JSON runtime events can feed this Actor: agent frameworks, observability pipelines, MCP gateways, workflow engines, API logs, audit logs or custom tracing systems.

Workflow: agent traces -> normalization -> policy evaluation -> permission/approval analysis -> runtime drift -> ranked findings -> ALLOW/REVIEW/BLOCK -> agentAction