Glossary
This page provides definitions of key terms and concepts used throughout the OpenBox documentation.
Activity
A single unit of work inside a Workflow: calling an LLM, querying a database, invoking a tool, or making an HTTP request. Activities are where side effects happen in Temporal.
OpenBox connection: OpenBox captures the inputs and outputs of every Activity execution, evaluates governance policies against them, and records a Governance Decision for each one.
Learn more: Temporal 101
Agent DID
The Decentralized Identifier assigned to every OpenBox agent, of the form did:aip:<uuidv5>. Derived deterministically from the agent's internal ID using UUIDv5 with the AIP namespace. The same agent always resolves to the same DID, and rotating the signing key does not change it. The DID appears in every signed governance request and on the agent's Settings page.
Learn more: Agent Identity (AIP)
Agent Lineage
The provenance model that connects an agent's repository changes, registered runtime, Agent DID, governed sessions, and governance configuration snapshots.
OpenBox connection: OpenBox shows lineage in Projects and in the agent detail Lineage tab when a runtime is linked to a project.
Learn more: Agent Lineage
Agent Paths
Included and ignored repository path rules that define which files belong to a Repository Agent. OpenBox uses these paths to decide whether a commit should become a lifecycle event for that agent.
Learn more: Projects
AIP (Agent Identity Protocol)
OpenBox's cryptographic agent identity layer. Each agent has an Ed25519 keypair; the SDK signs governance requests with the private key, and OpenBox verifies every signature against the non-extractable public key it holds for the agent. Runs alongside the existing API key: the bearer token authenticates the HTTP call, the AIP signature authenticates the agent that produced the payload.
Learn more: Agent Identity (AIP)
Risk Profile
A risk scoring framework that evaluates AI agents across three weighted categories:
| Category | Weight | Parameters |
|---|---|---|
| Base Security | 25% | Attack vector, attack complexity, privileges required, user interaction, scope |
| AI-Specific | 45% | Model robustness, data sensitivity, ethical impact, decision criticality, adaptability |
| Impact | 30% | Confidentiality, integrity, availability, safety impact |
The resulting score (0% – 100%) determines the agent's initial Trust Tier.
Learn more: Assess Phase
Alignment Score
A 0% – 100% metric measuring how well an agent's actions match its stated goals. Contributes 25% of the overall Trust Score.
| Range | Rating | Meaning |
|---|---|---|
| 90% – 100% | Excellent | Actions strongly aligned with goals |
| 70% – 89% | Good | Minor deviations, acceptable |
| 50% – 69% | Warning | Notable drift, review recommended |
| Below 50% | Misaligned | Significant deviation, action required |
Learn more: Verify Phase
Attestation
Cryptographic, tamper-proof evidence for every governance session. Each session's events are hashed into a Merkle Tree and digitally signed, creating a verifiable Proof Certificate that confirms no governance data was altered after the fact.
Signing providers:
- AWS KMS: ECDSA NIST P-256 (default)
- External Attestation: Your own signing service (e.g., TEE, HSM)
Learn more: Attestation & Cryptographic Proof
Behavioral Rules
Stateful authorization rules that detect multi-step patterns across an agent's session. Unlike Policies, behavioral rules track prior actions to identify sequences, frequencies, or combinations.
Pattern examples:
- Sequence: PII access → External API call (without approval)
- Frequency: More than 10 failed auth attempts in 1 minute
- Combination: Database write + File export + External send
Rules are evaluated in priority order and stop at the first rule that triggers a verdict.
Learn more: Authorize Phase: Behavioral Rules
Behavioral Score
A 0–100 runtime compliance metric that starts at 100 for new agents and decreases when policy violations occur. Contributes 35% of the overall Trust Score.
| Violation Severity | Penalty | Trust Score Impact |
|---|---|---|
| Minor | -5 pts | -1.75 pts |
| Major | -15 pts | -5.25 pts |
| Critical | -25 pts | -8.75 pts |
Learn more: Trust Scores
Governance Decision
The outcome produced when OpenBox evaluates an agent operation. There are five possible decisions, listed in precedence order:
| Decision | Effect | Impact |
|---|---|---|
| HALT | Terminates the entire agent session | Significant negative |
| BLOCK | Action rejected, agent continues | Negative |
| REQUIRE_APPROVAL | Operation paused for HITL review | Neutral (pending) |
| CONSTRAIN | Operation proceeds only through an integration that can enforce the returned constraints | Neutral (constrained) |
| ALLOW | Operation proceeds normally | Positive |
Precedence: HALT > BLOCK > REQUIRE_APPROVAL > CONSTRAIN > ALLOW
CONSTRAIN is not a logging-only form of ALLOW. Enforcement is integration-specific, and an integration that cannot apply the constraint must fail closed. Registered Temporal governed commands use sandbox execution when a policy returns constraints: ["run_in_sandbox"] or a behavioral rule selects a registered replacement profile; this does not mean every constrained action is sandboxed.
Learn more: Governance Decisions
Governance Snapshot
A point-in-time record of the policy, guardrail, and behavioral-rule version hashes associated with an agent runtime.
Snapshots are created when lineage-relevant context changes:
- Runtime linked to a project
- Commit touches the runtime's repository agent paths
- Policy version changes
- Guardrail version changes
- Behavioral-rule version changes
Learn more: Agent Lineage
Guardrail
Pre- or post-processing validation and transformation rules applied to agent inputs and outputs. Multiple guardrails execute as a chained pipeline: the output of one feeds into the next.
Types:
- Input Guardrails: Validate/transform incoming data (PII detection, rate limiting)
- Output Guardrails: Validate/transform responses (PII redaction, format enforcement)
Learn more: Authorize Phase: Guardrails
HITL (Human-in-the-Loop)
A workflow pattern where an agent operation is paused pending human approval before proceeding. Triggered by a REQUIRE_APPROVAL governance decision.
Approval actions:
| Action | Result | Trust Score Effect |
|---|---|---|
| Approve | Operation proceeds | No change |
| Reject | Operation blocked (reason required) | -2 pts |
| Timeout | Operation blocked after 5 minutes | -1 pt |
Learn more: Approvals
Lifecycle Event
A repository, branch, runtime-link, or governance event that changes the lineage context for an agent. Lifecycle events help explain how code and configuration changed over time for a specific repository agent or runtime.
Learn more: Projects
Merkle Tree
A cryptographic data structure used to combine individual event hashes into a single session root hash. Uses SHA-256 with sorted-pair hashing to ensure consistent tree construction regardless of processing order. Enables tamper-proof verification of governance events.
Learn more: Attestation & Cryptographic Proof
Policy (OPA/Rego)
Stateless permission checks written in OPA (Open Policy Agent) Rego language. Policies evaluate an input document at runtime and return a governance decision (CONTINUE or REQUIRE_APPROVAL) with an optional reason.
Unlike Behavioral Rules, policies are stateless: they evaluate each operation independently without tracking prior actions.
Learn more: Authorize Phase: Policies
Project
A repository-level grouping in OpenBox. One project maps to one connected repository and contains one or more Repository Agents.
OpenBox connection: Projects let OpenBox connect repository events to governed runtimes, sessions, and governance snapshots.
Learn more: Projects
Proof Certificate
A per-session attestation record produced after an agent session completes. Contains:
| Field | Description |
|---|---|
| Merkle Root | SHA-256 root hash of the session's event Merkle Tree |
| Signature | Digital signature of the Merkle root (from AWS KMS or external provider) |
| Event Count | Number of governance events included in the attestation |
Learn more: Attestation & Cryptographic Proof
Query
A synchronous, read-only request to inspect a running Workflow's state without affecting its execution. Queries return a value but never change the Workflow.
OpenBox connection: OpenBox uses Queries to inspect governance state during execution (for example, checking whether an approval is still pending). Queries do not trigger governance evaluation since they are read-only.
Learn more: Temporal 101
Repository Agent
The logical agent definition inside an OpenBox Project. A repository agent is defined by Agent Paths, which tell OpenBox which files belong to that agent.
OpenBox connection: In a monorepo, each repository agent can own different paths so commits are attributed to the correct agent.
Learn more: Projects
Runtime
A registered OpenBox agent instance with its own API key, Agent DID, sessions, and governance history. A runtime can be linked to a Project, Repository Agent, and branch for lineage.
Learn more: Agent Lineage
Session Replay
An interactive dashboard view showing the complete execution timeline of an agent session. Allows step-by-step walkthrough of every operation with its governance decision (ALLOW, BLOCK, REQUIRE_APPROVAL, etc.).
Learn more: Session Replay
Signing Required
A per-agent setting that controls whether OpenBox rejects unsigned governance requests. When On, requests that aren't signed by the agent's AIP identity are rejected; when Off, unsigned requests are still accepted. Operators toggle it from Agent Settings → API Access.
The toggle becomes available once an agent has a provisioned identity. Agents that predate the Agent Identity Protocol need to be provisioned first before the setting is available.
Learn more: Agent Identity (AIP)
Signal
An asynchronous message sent to a running Workflow from the outside. Signals let external systems inject data or trigger decisions mid-execution (for example, delivering a human approval result back to a paused agent).
OpenBox connection: OpenBox captures Signal data and evaluates governance policies on every Signal received. This is how HITL approvals flow back into the Workflow when a REQUIRE_APPROVAL decision pauses execution.
Learn more: Temporal 101
Task Queue
A named channel that connects Workflow/Activity starters to Workers. When you start a Workflow on a Task Queue, only Workers listening on that same queue will pick it up.
OpenBox connection: OpenBox preserves your existing Task Queue configuration. The wrapped Worker polls the same queue your original Worker used: governance is transparent to task routing.
Learn more: Temporal 101
Trust Layer
The governance layer OpenBox adds alongside your workflow engine. It provides trust scoring, policy enforcement, monitoring, and compliance evidence, without modifying your existing workflow code. Your workflow engine remains the system of record for execution.
Learn more: What is OpenBox?
Trust Lifecycle
OpenBox's 5-phase governance model for establishing, maintaining, and evolving trust in AI agents:
- Assess: Establish baseline risk profile
- Authorize: Define guardrails, policies, and behavioral rules
- Monitor: Observe runtime behavior and telemetry
- Verify: Check goal alignment and session integrity
- Adapt: Evolve trust based on observed patterns
Learn more: Trust Lifecycle Overview
Trust Score
A 0–100 metric representing an agent's overall trustworthiness, calculated from three components:
| Component | Weight | Description |
|---|---|---|
| Risk Profile Score | 40% | Inherent risk profile |
| Behavioral Score | 35% | Runtime compliance |
| Alignment Score | 25% | Goal consistency |
Formula: Trust Score = (Risk Profile × 40%) + (Behavioral × 35%) + (Alignment × 25%)
Learn more: Trust Scores
Trust Tier
One of five trust levels derived from the Trust Score that determines how strictly an agent is governed:
| Tier | Trust Score | Label | Description |
|---|---|---|---|
| Tier 1 | 90 – 100 | Trusted | Minimal oversight, most operations auto-approved |
| Tier 2 | 75 – 89 | Confident | Standard controls, approval for sensitive operations |
| Tier 3 | 50 – 74 | Monitor | Enhanced monitoring, stricter enforcement |
| Tier 4 | 25 – 49 | Restrict | Strict controls, frequent HITL, rate limiting |
| Untrusted | 0 – 24 | Decommission | Agent suspended, cannot operate |
Learn more: Trust Tiers
Worker
A process that hosts your Workflow and Activity code and polls Temporal for tasks to execute. You start a Worker, register your Workflows and Activities on it, and it handles execution.
OpenBox connection: The native Worker is the single integration point. Add OpenBoxPlugin to its plugins list (one code change that adds the Trust Layer); the plugin owns OpenBox setup for the Worker, Workflows, and Activities. Governed sandbox commands enter through OpenBoxPlugin(..., sandbox=SandboxConfig(...)) on that same Worker, where the plugin intercepts registered user Activities rather than exposing a second Worker or public plugin Activity.
Learn more: Temporal 101
Workflow
A durable function that orchestrates a sequence of steps. If the process crashes mid-execution, Temporal replays the Workflow from its event history so it can resume exactly where it left off.
OpenBox connection: When a Workflow starts, OpenBox creates a governance session. When it completes or fails, OpenBox closes the session and triggers Attestation. Every Workflow execution maps 1:1 to a governance session in your dashboard.
Learn more: Temporal 101