Glossary
Glossary
Section titled “Glossary”This glossary defines the core concepts used across Clasper documentation and products. It’s written for:
- Developers who may be new to GRC terminology.
- GRC/security teams who may be new to modern agent systems.
Agent Stack Fundamentals
Section titled “Agent Stack Fundamentals”An autonomous software entity that uses an LLM to reason, plan, and act toward a goal on behalf of a user or system.
Related: Agent Harness, LLM, Execution
Agent Harness
Section titled “Agent Harness”The orchestration layer that ties an agent’s LLM, skills, tools, session/memory, and data together. It is the “glue” that coordinates planning, tool calling, state, and retries.
Related: Tools, Skills, Session
User- or organization-specific information that grounds the agent: documents, repositories, tickets, policies, playbooks, incident history, and other context the agent should treat as “the world it operates in.”
LLM (Large Language Model)
Section titled “LLM (Large Language Model)”The reasoning engine (“brain”) that converts instructions + context into structured outputs (plans, tool calls, decisions, summaries). Examples include GPT and Claude families.
Related: Model, Provider, Token Usage
Memory
Section titled “Memory”Long-term context persistence and recall. In practice, memory is stored artifacts (notes, summaries, embeddings) used to provide stable, reusable context across sessions or executions.
Related: Memory Chunks, Context Selector, Vector Store
Session
Section titled “Session”A stateful interaction context that persists across turns (and sometimes across time). Sessions capture what has already happened so the agent doesn’t “start over” each message.
Skills
Section titled “Skills”Domain expertise modules: curated instructions, constraints, and permissions that package how to accomplish a task safely and repeatably.
Related: Skill Manifest, Skill Permissions, Tools
Single-purpose integrations agents call to take actions in the world (e.g., “create a ticket”, “read a file”, “run a query”, “call an API”). Clasper governs tool access and records tool activity for auditability.
Related: Tool Authorization, Tool Token, Adapter
Governance, Risk & Compliance (GRC)
Section titled “Governance, Risk & Compliance (GRC)”Approval
Section titled “Approval”A human authorization step required before an execution (or specific tool call) is allowed. Approvals are typically triggered by policy when risk, cost, or environment constraints demand it.
Related: Decision, Require Approval, Separation of Duties
Approval SLA
Section titled “Approval SLA”A time target for how quickly approvals should be resolved. SLAs are commonly used to drive alerting (e.g., “pending approvals older than N minutes”).
Related: Alert, Decision Status
Approval Token
Section titled “Approval Token”A short-lived token that proves a decision was approved and authorizes the continuation of execution under a bounded scope. In Cloud, approval tokens can be issued as externally verifiable artifacts.
Related: Decision Token, Attestation, Trust Root
Attestation
Section titled “Attestation”An externally verifiable cryptographic statement about an execution, decision, or evidence bundle. Attestations are what let third parties verify claims without trusting the operator.
Related: External Proof, Evidence Bundle, Signed Bundle
Audit Chain
Section titled “Audit Chain”A hash-linked (tamper-evident) chain of audit events. Each entry includes a hash of previous entries so edits or deletions are detectable.
Related: Audit Log, Tamper-evident, SHA256
Audit Entry
Section titled “Audit Entry”A single immutable event record in the audit log (e.g., “execution decision made”, “tool permission denied”, “override used”, “budget exceeded”).
Related: Audit Log, Trace Step
Audit Filter
Section titled “Audit Filter”A saved query configuration for retrieving audit entries by time range, event type, actor, workspace, environment, or other fields.
Related: Saved View, Audit Log
Audit Log
Section titled “Audit Log”An append-only record of governance-relevant events. Audit logs are the primary source of “who did what, when, under what authorization.”
Related: Audit Chain, Export Bundle, Compliance
Budget
Section titled “Budget”A cost control boundary for agent activity (e.g., monthly tenant budget, per-workspace spend ceiling, or per-execution maximum).
Related: Budget Check, Hard Limit, Cost Forecast
Budget Check
Section titled “Budget Check”A pre-execution evaluation that decides whether there is enough remaining budget to proceed (and whether to warn or block).
Related: Budget, Hard Limit, Soft Limit
Compliance
Section titled “Compliance”The practices, controls, and evidence required to satisfy legal, regulatory, or security program requirements (e.g., SOC 2, ISO 27001). In Clasper, compliance depends on auditability, integrity, retention, and externally verifiable proof when required.
Related: Retention, External Proof, Audit Log
Compliance Export
Section titled “Compliance Export”A report or export bundle tailored for compliance workflows (audits, evidence collection, incident response). Cloud systems can provide stronger guarantees (e.g., retention, external proof).
Related: Export Bundle, Verifiable Export
The monetary cost of model usage for an execution, typically derived from token usage and model pricing.
Related: Token Usage, Model Pricing, Budget
Cost Forecast
Section titled “Cost Forecast”An estimate of expected cost before execution, based on prompt size, model choice, and pricing.
Related: Budget Check, Model Pricing
Data Sensitivity
Section titled “Data Sensitivity”A classification of how sensitive the data involved in an execution is (none/low/medium/high/PII). Sensitivity influences redaction, risk scoring, and approval requirements.
Related: Redaction, PII Detection, Risk Level
Decision
Section titled “Decision”The result of governance evaluation for a requested execution or tool call. Decisions commonly include allow, deny, or require_approval (and may include pending for async approval flows).
Related: Execution Decision, Policy, Decision Trace
Decision Status
Section titled “Decision Status”The lifecycle state of a decision request, such as pending, approved, denied, or expired.
Related: Approval, Decision Token
Decision Token
Section titled “Decision Token”A short-lived, scoped, often single-use token that authorizes an approved decision. Tokens are typically bound to tenant/workspace/adapter/execution and may be consumed to prevent replay.
Related: Approval Token, Tool Token
Decision Trace
Section titled “Decision Trace”A machine-readable explanation of why a decision was reached: which policies matched, what conditions were evaluated, and what precedence rules applied.
Related: Policy, Matched Policies, Explainability
Evidence Bundle
Section titled “Evidence Bundle”A collected set of artifacts that support an audit/compliance claim (e.g., decision record, trace, policy bundle hash, receipts). Bundles can be signed to produce external proof.
Related: Attestation, Signed Bundle, Export Bundle
Explainability
Section titled “Explainability”The ability to show understandable, attributable reasons for governance outcomes (allows/denies/approvals). In Clasper, explainability is delivered via decision traces and matched-policy outputs.
Related: Decision Trace, Policy Evaluation
Export Bundle
Section titled “Export Bundle”An export of governance artifacts (audit log, traces, decisions, policy data) for offline review. In open-source deployments, exports are often self-attested.
Related: Self-Attested Evidence, Verifiable Export
External Proof
Section titled “External Proof”Evidence that can be verified by someone who does not trust the operator. Achieved via cryptographic signing, stable hashing, and trusted issuance (e.g., Cloud-backed attestations).
Related: Attestation, Trust Root, Tamper-evident
Hard Limit
Section titled “Hard Limit”A budget or policy limit that blocks execution when exceeded.
Related: Soft Limit, Budget
Local Override
Section titled “Local Override”A manual exception that changes the governance result (e.g., allow something denied) while recording justification and marking the event as less trusted.
Related: Decision, Audit Log, Trust Status
Matched Policies
Section titled “Matched Policies”The ordered list of policies that matched a request during evaluation. Used for both machine reasoning and human explainability.
Related: Policy Precedence, Decision Trace
Model Pricing
Section titled “Model Pricing”A pricing table that maps model identifiers to per-token costs used for forecasting and cost accounting.
Related: Cost Forecast, Token Usage
PII (Personally Identifiable Information)
Section titled “PII (Personally Identifiable Information)”Data that can identify an individual (names, emails, phone numbers, IDs, etc.). Handling PII typically requires stricter logging controls, redaction, and approval workflows.
Related: PII Detection, Redaction, Data Sensitivity
PII Detection
Section titled “PII Detection”Mechanisms (often pattern-based) for detecting PII and other secrets (API keys, JWTs, credit cards) in traces, prompts, and tool outputs.
Policy
Section titled “Policy”A declarative rule that determines whether an execution/tool call is allowed, denied, or requires approval, based on scope and conditions.
Related: Policy Scope, Policy Conditions, Policy Evaluation
Policy Bundle
Section titled “Policy Bundle”A packaged set of policies treated as a unit for distribution, promotion, versioning, and signing.
Related: Signed Bundle, Policy Promotion
Policy Conditions
Section titled “Policy Conditions”Fields that must match for a policy to apply (e.g., adapter risk class, requested capability, provenance source, risk level, cost thresholds). Missing fields are typically treated as “unknown,” not “false.”
Related: Policy Evaluation, Execution Context Signals
Policy Evaluation
Section titled “Policy Evaluation”The process of comparing a request (execution/tool authorization) against policies to compute a decision.
Related: Decision, Policy Precedence
Policy Precedence
Section titled “Policy Precedence”A deterministic rule for choosing between multiple matching policies. Typically expressed as a numeric priority where higher precedence wins.
Related: Matched Policies
Policy Promotion
Section titled “Policy Promotion”Moving policies through environments (e.g., dev → staging → prod). In Cloud systems, promotion can be signed and auditable to prevent tampering.
Related: Environment, Signed Bundle
Policy Lifecycle
Section titled “Policy Lifecycle”The end-to-end process of managing policies over time: authoring, review, testing/dry-run, approval, promotion across environments, monitoring, and eventual deprecation. A clear lifecycle reduces “silent governance changes” and makes audits tractable.
Related: Policy Promotion, Policy Rollback, Decision Trace
Policy Rollback
Section titled “Policy Rollback”Reverting policy state to a previously known-good version after a bad change (e.g., an overly strict deny or an overly broad allow). Rollbacks should be auditable and ideally bound to signed policy bundles or versioned policy data.
Related: Policy Bundle, Policy Lifecycle, Audit Log
Policy Scope
Section titled “Policy Scope”The boundary where a policy applies (tenant/workspace/environment, and sometimes adapter/tool/skill).
Related: Tenant, Workspace, Environment
Policy Subject
Section titled “Policy Subject”What the policy governs (e.g., adapter, tool, skill, environment, risk, cost). Subjects help avoid overly broad “blanket” policies.
Related: Policy, Policy Conditions
Redaction
Section titled “Redaction”Masking, hashing, dropping, or summarizing sensitive data before it is stored or shared (e.g., removing secrets from logs and traces).
Related: PII Detection, Trust Status
Require Approval
Section titled “Require Approval”A governance outcome that halts execution until a human reviewer approves. This is used for high-risk capabilities, production environments, unusual provenance, or high cost.
Related: Approval, Decision Status
Retention
Section titled “Retention”How long audit logs, traces, and evidence are kept, and under what immutability and deletion guarantees. Retention policies commonly specify duration, scope (tenant/workspace/environment), and storage mode (e.g., full retention vs sampling), and are a core compliance control.
Related: Audit Log, Tamper-evident, Compliance
Risk Factors
Section titled “Risk Factors”Concrete reasons that increase risk (e.g., broad tool access, external network, untrusted provenance, high-privilege actions, sensitive data).
Related: Risk Score, Execution Context Signals
Risk Level
Section titled “Risk Level”A categorical classification (none/low/medium/high/critical) derived from a risk score and policy context. Used for policy matching and approval gating.
Related: Risk Score, Policy Conditions
Risk Recommendations
Section titled “Risk Recommendations”Suggested mitigations to reduce risk (e.g., pin skill versions, narrow tool permissions, lower model volatility, require approvals in prod).
Related: Risk Factors, Skill Pinning
Risk Score
Section titled “Risk Score”A numeric assessment of execution risk (often 0–100) computed from factors like capability breadth, data sensitivity, provenance, adapter risk class, and model settings.
Related: Risk Level, Risk Factors
Self-Attested Evidence
Section titled “Self-Attested Evidence”Evidence generated and stored by the operator without an external trust anchor. It can be useful operationally but cannot prove claims to a skeptical third party.
Related: External Proof, Export Bundle
Separation of Duties
Section titled “Separation of Duties”A control ensuring that high-impact actions require multiple people or roles (e.g., one person requests, another approves). Common in regulated environments.
Signed Bundle
Section titled “Signed Bundle”A policy bundle or evidence bundle with a cryptographic signature, enabling external verification of integrity and provenance.
Related: Attestation, Trust Root
Soft Limit
Section titled “Soft Limit”A budget or policy limit that triggers warnings but may still allow execution (depending on configuration).
Related: Hard Limit, Budget
Tamper-evident
Section titled “Tamper-evident”A property where modifications are detectable (e.g., via hashing, chaining, signing). Tamper-evidence does not necessarily prevent changes; it makes them provable.
Related: Audit Chain, Signed Bundle
Token Usage
Section titled “Token Usage”Counts of input and output tokens consumed by model calls. Token usage is used for cost accounting and can be governed by policy and budgets.
Related: Cost, Model Pricing
Trust Root
Section titled “Trust Root”The authoritative system/key material that can issue signatures, attestations, or approval tokens that others can verify. Trust roots are central to external proof.
Related: External Proof, Attestation
Trust Status
Section titled “Trust Status”A label attached to traces/evidence that summarizes integrity and enforcement results, such as verified, verified_with_violations, unverified, or compromised.
Related: Trace Integrity, Violations
Verifiable Export
Section titled “Verifiable Export”An export bundle that includes enough hashes/signatures/receipts to verify integrity offline.
Related: Export Bundle, External Proof
Agent Configuration & Lifecycle
Section titled “Agent Configuration & Lifecycle”AGENTS.md (Operating Rules)
Section titled “AGENTS.md (Operating Rules)”A workspace file defining how agents should behave: style, constraints, escalation rules, and operational boundaries for consistent execution.
Agent ID
Section titled “Agent ID”A unique identifier for an agent in multi-agent runtimes (e.g., OpenClaw, CrewAI). Adapters include agent_id in execution requests; policies can match on it for per-agent governance (budgets, quarantine, capability scoping).
Related: Agent Role, Policy Conditions
Agent Role
Section titled “Agent Role”A named role for an agent (e.g., “lead”, “researcher”, “writer”). Roles are used for identity, policy scoping, and role-specific configuration.
Related: IDENTITY.md, RBAC
Agent Token
Section titled “Agent Token”A JWT (or similar credential) used by an agent to authenticate to a control plane or governance system. Typically includes user_id and agent_role.
Related: JWT, Control Plane
Context
Section titled “Context”The information provided to an LLM for a specific step: system rules, user instructions, selected memory/documents, and relevant execution signals. Context is always bounded by a model’s context window, so selection and summarization matter.
Related: Context Selector, Session, Token Usage, Execution Context Signals
Context Selector
Section titled “Context Selector”A component that selects relevant memory, skills, and documents to include in the prompt context based on the current request (often using hybrid search).
Related: Memory Chunks, Vector Store
Embedding
Section titled “Embedding”A numeric vector representation of text that preserves semantic similarity. Embeddings power semantic search and retrieval (“find things like this”) over memory and workspace content.
Related: Embedding Provider, Vector Store
Embedding Provider
Section titled “Embedding Provider”The service/library used to generate embeddings for text (often separate from the LLM used for reasoning). Providers affect quality, cost, latency, and privacy posture.
Memory Chunks
Section titled “Memory Chunks”Smaller segments of memory or documents that are indexed and retrieved individually. Chunking improves retrieval quality and keeps prompt context bounded.
Related: Context Selector, Token Usage
Vector Store
Section titled “Vector Store”A storage/index for embeddings that supports similarity search. Vector stores are used to retrieve relevant memory chunks and workspace artifacts for an execution.
Related: Embedding, Memory Chunks, Context Selector
Workspace Index
Section titled “Workspace Index”A searchable index over workspace content (skills, docs, memory, configs) used for retrieval and governance explainability. Indexes can include both full-text and embedding-based search.
Related: Workspace, Context Selector
Execution
Section titled “Execution”A single run of an agent/harness performing work in response to input. Executions are tracked by identifiers and recorded as traces.
Related: Execution ID, Trace, Execution Decision
Execution Context Signals
Section titled “Execution Context Signals”Optional structured fields included with an execution request (e.g., intent, context.external_network, writes_files, elevated_privileges, package_manager, provenance). These improve policy matching and approval UX.
Related: Intent (Agent Intent), Policy Conditions, Provenance
Intent (Agent Intent)
Section titled “Intent (Agent Intent)”A short, human-readable statement of why an execution is being requested (e.g. “install_dependency”, “run_tests”, “deploy_staging”). The adapter (or harness) sends it optionally on the execution request. Clasper uses it for policy matching (policies can match on intent for targeted allow/deny/approval), approval UX (reviewers see purpose without raw commands), and observability (trace titles and labels use intent when present). If intent is omitted, it is treated as unknown for policy evaluation.
Related: Execution Context Signals, Policy Conditions, Trace, Adapter
Execution Decision
Section titled “Execution Decision”The governance output for a requested execution, granting a bounded scope (capabilities, cost/steps/time limits) or denying/pending approval.
Related: Decision, Execution Scope
Execution ID
Section titled “Execution ID”A unique identifier for an execution request/run, used for attribution and correlation across decisions, traces, and audit entries.
Execution Scope
Section titled “Execution Scope”The bounded authorization granted to proceed: allowed capabilities, maximum steps, maximum cost, expiration time, and other constraints.
Related: Granted Scope, Capability
HEARTBEAT.md
Section titled “HEARTBEAT.md”A workspace checklist used for routine “health checks” by the agent (e.g., what to verify each day before/while operating).
IDENTITY.md
Section titled “IDENTITY.md”A workspace file defining agent identity metadata (name/role/presentation). Used for consistent attribution in messages and traces.
Related: Agent Role, Trace
Prompt Injection
Section titled “Prompt Injection”An attack where untrusted text (web pages, tickets, docs) tries to manipulate the agent into ignoring system instructions or exfiltrating secrets. Governance systems typically treat untrusted content as data and apply sanitization/redaction.
Related: Prompt Injection Prevention, Redaction
Session Key
Section titled “Session Key”A stable identifier for an agent session used to group activity across time (often combining user + agent role).
Related: Session, Agent Token
SOUL.md (Agent Persona)
Section titled “SOUL.md (Agent Persona)”A workspace file that defines the agent’s persona: tone, boundaries, and behavioral constraints. Unlike policies (governance), SOUL focuses on interaction style and intent.
A structured record of an execution: steps, tool calls, results, timing, cost, risk, trust status, and outputs. Traces are the primary unit of observability and accountability.
Related: Trace Step, Audit Log
Trace Annotations
Section titled “Trace Annotations”Append-only metadata attached to traces after the fact (e.g., incident tags, reviewer notes, classification).
Related: Labels, Audit Entry
Trace Diff
Section titled “Trace Diff”A comparison of two traces to identify changes in behavior, scope, cost, risk, or outcomes (useful for regression analysis and skill changes).
Related: Trace Replay, Drift
Trace ID
Section titled “Trace ID”A unique identifier for the trace of an execution, used to retrieve and correlate observability records.
Related: Execution ID
Trace Integrity
Section titled “Trace Integrity”The integrity verification result for a trace (e.g., verified vs compromised) based on hashing, signatures, chaining, and enforcement signals.
Related: Trust Status, Signed Telemetry
Trace Replay
Section titled “Trace Replay”Re-running an execution using the same recorded inputs, workspace versions, and pinned skills to reproduce behavior for debugging or audits.
Related: Workspace Hash, Skill Pinning
Trace Step
Section titled “Trace Step”An individual unit inside a trace (e.g., model call, tool call, tool result, error). Steps are what make traces inspectable.
Execution Graph
Section titled “Execution Graph”A visual flow in the trace detail view showing the execution pipeline: Prompt → Policy decision → Approval (if applicable) → Reasoning (LLM calls) → Tool call → Execution (tool results). Helps operators quickly understand governance gates and step sequence.
Related: Trace, Trace Step
Skills
Section titled “Skills”Draft (Skill State)
Section titled “Draft (Skill State)”A skill state indicating it is under development and not yet trusted for routine execution.
Related: Skill State
Deprecated (Skill State)
Section titled “Deprecated (Skill State)”A skill lifecycle state indicating it should no longer be used, typically because it is replaced, insecure, or outdated.
Related: Skill State, Risk Recommendations
Environment Promotion
Section titled “Environment Promotion”Moving a workspace or skill configuration through environments (dev → staging → prod) with checks to prevent unsafe changes from reaching production.
Related: Workspace Environment, Policy Promotion
Gates (Skill Gates)
Section titled “Gates (Skill Gates)”Preconditions a skill requires to run safely (OS, binaries, environment variables, network constraints). Gates prevent skills from running in incompatible environments.
Related: Skill Manifest
Published Skill
Section titled “Published Skill”A versioned skill artifact stored in a registry with metadata, checksum, and lifecycle state.
Related: Skill Registry, Skill Checksum
A packaged unit of capability: instructions + constraints + permissions + tests that can be versioned and promoted.
Related: Skill Manifest, Skill Permissions
Skill Checksum
Section titled “Skill Checksum”A SHA256 (or similar) digest computed over skill contents to detect changes and support pinning/version verification.
Related: SHA256, Skill Pinning
Skill Manifest
Section titled “Skill Manifest”A structured definition of a skill (commonly YAML) including description, inputs/outputs, permissions, gates, instructions, and sometimes tests.
Related: Skill Permissions, Gates (Skill Gates)
Skill Permissions
Section titled “Skill Permissions”The explicit list of tools/models/tokens/capabilities a skill is allowed to use. Permissions enable default-deny governance at a fine granularity.
Related: Default-deny, Tool Permissions
Skill Pinning
Section titled “Skill Pinning”Locking a workspace or environment to a specific skill version/checksum so changes cannot silently alter behavior.
Related: Workspace Pin, Drift
Skill Registry
Section titled “Skill Registry”A storage system for versioned skills and metadata, enabling discovery, publishing, promotion, and lifecycle enforcement.
Related: Skill State
Skill State
Section titled “Skill State”The lifecycle stage of a skill (e.g., draft → tested → approved → active → deprecated). States enforce governance and reduce accidental risk.
Related: Risk Level, Approval
Tested (Skill State)
Section titled “Tested (Skill State)”A skill state indicating it has passed defined tests and validations, but may still require approval before activation.
Related: Skill State
Tools & Execution
Section titled “Tools & Execution”Adapter
Section titled “Adapter”An execution client that requests governance decisions and then performs execution under granted scope. Adapters are explicitly treated as clients (never peers) and must authenticate.
Related: Adapter Contract, Adapter Token, Execution Decision
Adapter Capabilities
Section titled “Adapter Capabilities”The set of capabilities an adapter can request or perform (e.g., shell execution, network calls). Capability breadth is a primary risk driver.
Related: Capability, Risk Score
Adapter Contract
Section titled “Adapter Contract”The API contract between Clasper Core and adapters: how to request execution decisions, ingest telemetry, and handle tool authorization.
Related: Control Plane Contract, Telemetry Ingest
Adapter Risk Class
Section titled “Adapter Risk Class”A classification assigned to an adapter indicating how risky it is as an executor (low/medium/high/critical). Policies can match on risk class.
Related: Risk Level, Policy Conditions
Adapter Telemetry
Section titled “Adapter Telemetry”Trace/cost/metrics/violation data sent from adapters back to the governance system for observability and audits.
Related: Telemetry Ingest, Signed Telemetry
Adapter Token
Section titled “Adapter Token”A JWT (or similar) credential that authenticates an adapter to Clasper endpoints, typically scoped to tenant/workspace/adapter and allowed capabilities.
Related: JWT, Adapter Auth
Capability
Section titled “Capability”A named permission representing an action class (e.g., shell.exec, network.http, files.write). Capabilities are what governance primarily grants or denies.
Related: Execution Scope, Granted Scope
Default-deny
Section titled “Default-deny”A security posture where execution is not allowed unless explicitly permitted by policy and/or approval. Default-deny reduces unexpected privilege escalation.
Related: Policy, Skill Permissions
Granted Scope
Section titled “Granted Scope”The concrete set of allowed capabilities and limits granted by a decision (time/cost/steps/tool permissions). “Scope” is what makes approval safe.
Related: Execution Scope, Decision Token
MCP (Model Context Protocol)
Section titled “MCP (Model Context Protocol)”A protocol pattern for long-lived model/server interactions (contrasted with “cold-start” invocations). In Clasper ecosystems it may be used to describe tool servers or agent integrations.
Runtime Adapter
Section titled “Runtime Adapter”An adapter implementation that runs execution in-process (often as a “built-in” executor) rather than as an external system.
Tool Authorization
Section titled “Tool Authorization”A governance step required before calling a sensitive tool. Authorization typically returns a short-lived token bound to the execution, tool, and scope.
Related: Tool Token, Policy Evaluation
Tool Permissions
Section titled “Tool Permissions”Rules that determine which tools may be called under what conditions (based on skill permissions, policies, and risk).
Related: Skill Permissions, Policy
Tool Proxy
Section titled “Tool Proxy”The component that validates tool calls (schema + path safety + authorization) and routes execution to the appropriate backend/integration.
Related: Path Validation, Tool Authorization
Tool Token
Section titled “Tool Token”A short-lived token proving a tool call is authorized for a specific execution and scope. Tool tokens are typically single-use to reduce replay risk.
Related: Tool Authorization, JWT
Plugins
Section titled “Plugins”Allowlist
Section titled “Allowlist”A configuration list that explicitly permits only specified plugins (or IDs) to load. Allowlisting is a defense-in-depth measure.
Related: Denylist, Plugin Loader
A referenced ecosystem/tooling name associated with OpenClaw-style plugin manifest documentation (used as a conceptual reference).
Related: OpenClaw
Command (Plugin Command)
Section titled “Command (Plugin Command)”An executable command registered by a plugin (distinct from tools). Commands are often higher-level operations or workflows.
Config Schema
Section titled “Config Schema”A JSON schema describing how a plugin’s configuration should be validated and rendered.
Related: UI Hints, Plugin Manifest
Denylist
Section titled “Denylist”A list of patterns or identifiers that are blocked (e.g., prompt guard denylist patterns). Denylists are commonly used to prevent known-bad inputs.
Related: Prompt Guard, Allowlist
Entrypoint
Section titled “Entrypoint”A discovery mechanism (often language/runtime specific) used to locate and load plugins from installed packages or configured paths.
Related: Plugin Discovery, Plugin Loader
A function invoked before/after certain operations (e.g., before task creation). Hooks can enforce policy by blocking requests or annotating activity.
Related: Pre-request Hook, Post-request Hook
Manifest (Plugin Manifest)
Section titled “Manifest (Plugin Manifest)”A plugin metadata file (e.g., openclaw.plugin.json) defining id, version, entrypoint, kind, and configuration schema.
Related: Plugin, Plugin Loader
OpenClaw
Section titled “OpenClaw”A manifest-driven plugin model referenced by the control plane starter. “OpenClaw-style” typically means “plugins are discovered via manifests and register themselves via a runtime API.”
Related: Plugin Runtime, Plugin Registry
Plugin
Section titled “Plugin”An extension module that adds capabilities via hooks, tools, commands, or services.
Related: Plugin Registry, Plugin Runtime
Plugin Discovery
Section titled “Plugin Discovery”The process of finding plugins across configured directories, installed packages, or entrypoint groups.
Related: Plugin Loader, Entrypoint
Plugin Kind
Section titled “Plugin Kind”A category label for a plugin (e.g., “memory”). Kinds are often used for slotting and UI grouping.
Related: Slots
Plugin Loader
Section titled “Plugin Loader”The component that discovers, validates, and loads plugins according to config (allow/deny lists, paths, entrypoints).
Related: Plugin Config, Plugin Discovery
Plugin Config
Section titled “Plugin Config”Configuration controlling which plugins are enabled, how they are discovered, and which slots/kinds are populated.
Plugin Registry
Section titled “Plugin Registry”The runtime store for plugin-registered hooks/tools/commands/services, typically keyed by name or plugin ID.
Plugin Runtime
Section titled “Plugin Runtime”The API object passed to plugins during registration, exposing methods like register_tool, register_hook, register_command, and configuration access.
Related: Register Function
Post-request Hook
Section titled “Post-request Hook”A hook run after an operation succeeds (e.g., after a task is created). Often used for logging, event emission, or enrichment.
Related: Hook
Pre-request Hook
Section titled “Pre-request Hook”A hook run before an operation (e.g., before posting a message). Often used for validation and blocking (raise “plugin blocked”).
Related: Prompt Guard, Plugin Blocked
Prompt Guard
Section titled “Prompt Guard”A security plugin that blocks requests matching denylist patterns (commonly used to block known-bad prompt injection strings or exfil attempts).
Related: Denylist, Plugin Blocked
Plugin Blocked
Section titled “Plugin Blocked”An error/exception raised when a plugin blocks an operation (often returning HTTP 403). It indicates an enforced policy violation in plugin space.
Related: Pre-request Hook, Policy
Register Function
Section titled “Register Function”The entrypoint function a plugin exposes to register itself with the plugin runtime/registry.
Related: Manifest (Plugin Manifest), Plugin Runtime
Service (Plugin Service)
Section titled “Service (Plugin Service)”A long-running background component registered by a plugin.
Related: Command (Plugin Command)
Exclusive categories where only one plugin may occupy a slot (e.g., only one “memory” plugin enabled at a time).
Related: Plugin Kind, Plugin Config
UI Hints
Section titled “UI Hints”Metadata that guides how plugin config fields should be rendered in UIs (labels, descriptions, input types).
Related: Config Schema
Infrastructure & Architecture
Section titled “Infrastructure & Architecture”Clasper Cloud
Section titled “Clasper Cloud”The hosted multi-tenant console and governance layer that aggregates fleet telemetry, manages approvals and alerting, and can issue externally verifiable proof.
Related: Fleet, External Proof, RBAC
Clasper Core
Section titled “Clasper Core”The open-source governance engine. Core evaluates policies, issues execution decisions, records audit logs, stores traces, and exports evidence bundles.
Related: Governance Plane, Policy
Control Plane
Section titled “Control Plane”The system that agents communicate with to create tasks, post messages, store documents, and request capabilities. It is distinct from governance (Core) but integrates with it.
Related: Mission Control, Control Plane Contract
Control Plane Contract
Section titled “Control Plane Contract”The API specification a control plane implementation must satisfy (capabilities, tasks, messages, documents, optional SSE/notifications).
Related: Contract Version, Capabilities
Contract
Section titled “Contract”A formal description of required API endpoints, request/response shapes, and behavior guarantees between components (e.g., adapters ↔ core, control plane ↔ clients).
Related: Adapter Contract, Control Plane Contract
Contract Version
Section titled “Contract Version”The version string identifying the contract revision supported by a component (e.g., v1).
Related: Capabilities
Environment
Section titled “Environment”An operational context such as dev/staging/prod. Environments are used to scope policies, pin versions, and enforce stricter controls in production.
Related: Workspace Environment, Policy Promotion
A collection of multiple Clasper instances managed together. Fleet views are primarily a Cloud concept for centralized oversight.
Related: Instance, Fleet Governance
Fleet Governance
Section titled “Fleet Governance”Governance policies and workflows applied consistently across many instances/environments (Cloud-oriented concept).
Related: Policy Bundle, Policy Promotion
Fleet Visibility
Section titled “Fleet Visibility”Aggregated dashboards and telemetry across a fleet (cost, risk, violations, approvals) rather than per-instance only.
Related: Dashboard, SSE Fan-out
Governance Plane
Section titled “Governance Plane”The layer that decides what is allowed and under what constraints, and produces audit/evidence artifacts. Clasper Core is a governance plane.
Related: Execution Decision, Audit Log
Instance
Section titled “Instance”A registered deployment that connects to Cloud for aggregation and management. Instances typically report status and stream events.
Related: Instance Status, Health Check
Instance Health Check
Section titled “Instance Health Check”A periodic check to verify an instance is reachable and healthy (often recorded with timestamps).
Related: Instance
Instance Status
Section titled “Instance Status”A connectivity/health state such as connected, disconnected, or error.
Related: Instance
Mission Control
Section titled “Mission Control”The API namespace/prefix used by the control plane for contract endpoints (often /api/mission-control/...).
Related: Control Plane, Capabilities
Multi-tenant
Section titled “Multi-tenant”An architecture that serves multiple organizations (“tenants”) with isolation boundaries between them.
Related: Tenant, Single-tenant
Single-tenant
Section titled “Single-tenant”An architecture designed for one operator/organization. Many open-source deployments are single-tenant and use self-attested evidence.
Related: Self-Attested Evidence
An organizational grouping of users in Cloud governance with shared instances, dashboards, and policies.
Related: RBAC, Team Member
Team Member
Section titled “Team Member”A user belonging to a team with a role (owner/admin/member/viewer) controlling access to governance operations.
Tenant
Section titled “Tenant”The primary organizational unit for isolation in multi-tenant systems (a customer/org boundary).
Tenant ID
Section titled “Tenant ID”A unique identifier for a tenant used for scoping data, policies, and decisions.
Related: Policy Scope
Workspace
Section titled “Workspace”A logical and/or filesystem-scoped boundary for agent configuration and operation (skills, persona, memory, pins). Policies and retention can be scoped to a workspace.
Related: Workspace Hash, Workspace Pin
Workspace Environment
Section titled “Workspace Environment”A named environment within a workspace (dev/staging/prod) used for pinning versions and promoting changes through checks.
Related: Environment Promotion
Workspace Hash
Section titled “Workspace Hash”A stable digest of workspace content (skills, persona files, memory, etc.) used for versioning, trace replay, and integrity checking.
Related: Trace Replay, SHA256
Workspace Pin
Section titled “Workspace Pin”A binding from an environment to a specific workspace version/hash to prevent silent drift.
Related: Skill Pinning, Drift
Security & Authentication
Section titled “Security & Authentication”Adapter Auth
Section titled “Adapter Auth”Authentication mechanism for adapters (commonly JWT via X-Adapter-Token) that limits adapter scope to allowed capabilities and tenant/workspace boundaries.
Related: Adapter Token, JWT
Agent Auth (JWT)
Section titled “Agent Auth (JWT)”Authentication mechanism for agents (commonly JWT via X-Agent-Token) that attributes actions to a user_id and agent_role.
Related: Agent Token, JWT
API Token
Section titled “API Token”A credential used to authenticate an instance to Cloud services. Often stored/verified as a hash server-side.
Related: API Token Hash
API Token Hash
Section titled “API Token Hash”A cryptographic hash stored instead of the raw API token, reducing the blast radius if a database is leaked.
Related: SHA256
Authentication
Section titled “Authentication”The process of verifying identity (user, agent, adapter, or instance) before allowing access to APIs or privileged operations. Authentication answers “who are you?” (authorization answers “what can you do?”).
Related: Authorization, JWT, OIDC
Authorization
Section titled “Authorization”The process of enforcing permissions after identity is known. Authorization answers “what are you allowed to do?” and is typically implemented via scopes, capabilities, and RBAC roles.
Related: RBAC, Granted Scope, Capability
Key Management
Section titled “Key Management”The practices and systems used to generate, store, rotate, and use cryptographic keys and secrets safely. In the Clasper context this includes signing keys (for attestations/bundles), verification keys (adapter public keys), and token secrets (JWT/API token material), plus auditing and rotation procedures.
Related: Trust Root, Signed Bundle, Signed Telemetry, Secrets
JSON Web Token: a compact, signed credential that carries claims (who you are, what you can do) and can be verified by the receiver.
Related: Trust Root, RBAC
OpenID Connect: an identity layer on top of OAuth 2.0 used for single sign-on and federation.
Related: Authentication
Ops Auth (API Key)
Section titled “Ops Auth (API Key)”Authentication for operational/admin endpoints, often using a local API key for a single-operator console.
Related: Ops Console
Path Validation
Section titled “Path Validation”Security checks to prevent path traversal or unsafe filesystem access in tool arguments (e.g., ensuring paths stay within an allowed workspace).
Related: Tool Proxy, Tools
Prompt Injection Prevention
Section titled “Prompt Injection Prevention”Techniques to reduce prompt injection risk: sanitization, content compartmentalization, denylist/allowlist controls, and strict policy gates on exfiltration-prone tools.
Related: Prompt Injection, Prompt Guard
Role-Based Access Control: permissions are granted to roles, and users are assigned roles. RBAC is commonly used for approval requirements and separation of duties.
Related: Role, Required Role
Required Role
Section titled “Required Role”The minimum RBAC role needed to approve or perform a privileged operation.
An access level assigned to a user (e.g., owner/admin/member/viewer) that determines permitted actions.
Related: RBAC
Secrets
Section titled “Secrets”Sensitive credentials (API keys, tokens, passwords) that must be protected from exposure in logs, traces, and prompts.
Related: Redaction, PII Detection
SHA256
Section titled “SHA256”A cryptographic hash function used for integrity: checksums, bundle hashes, workspace hashes, token hashes, and chain links.
Related: Stable JSON, Audit Chain
Signed Telemetry
Section titled “Signed Telemetry”Telemetry envelopes (trace/cost/violations) signed by an adapter so the receiver can verify integrity and provenance.
Related: Trace Integrity, Tamper-evident
Stable JSON
Section titled “Stable JSON”Deterministic JSON serialization used so hashing the “same data” always produces the same digest (critical for signatures and verifiable exports).
Related: SHA256, Signed Bundle
Observability & Operations
Section titled “Observability & Operations”A notification triggered when a governance/ops condition is met (risk threshold exceeded, budget exceeded, policy violations, approval SLA breached).
Related: Alert Rule, Alert Channel
Alert Channel
Section titled “Alert Channel”How an alert is delivered (email, Slack, webhook).
Related: Alert
Alert Condition
Section titled “Alert Condition”The predicate that triggers an alert (e.g., “risk ≥ high”, “cost threshold exceeded”, “error rate high”).
Related: Alert Rule
Alert Event
Section titled “Alert Event”An instance of a triggered alert, including timestamp and payload.
Related: Alert
Alert Rule
Section titled “Alert Rule”The configuration defining conditions, scope, and channels for alerts.
Related: Saved View
Capabilities
Section titled “Capabilities”A reported set of feature flags and supported endpoints for a component (often returned by control plane “capabilities” endpoints).
Related: Contract Version
Dashboard
Section titled “Dashboard”A UI view showing aggregated metrics and trends (risk, cost, approvals, violations).
Related: Saved View
Unintended change in behavior over time due to unpinned skills, workspace changes, model changes, or policy changes.
Related: Skill Pinning, Workspace Pin
Evaluation Results
Section titled “Evaluation Results”Stored outcomes from automated evaluation runs (datasets, scores, drift signals) used to detect regressions and verify skills/models.
Related: Drift
Event Bus
Section titled “Event Bus”An internal publish/subscribe mechanism used to fan out events to subscribers within the system.
Related: SSE
Error Rate
Section titled “Error Rate”The proportion of executions or steps that fail over a window. Often used for operational alerting.
Related: Alert Condition
Health Check
Section titled “Health Check”An endpoint or mechanism verifying a service is alive and responsive (often /health).
Related: Instance Health Check
Heartbeat (SSE)
Section titled “Heartbeat (SSE)”A keepalive message in event streams used to prevent timeouts and detect disconnects.
Related: SSE
Labels
Section titled “Labels”Key-value metadata attached to traces (and sometimes audits) to support filtering, routing, and incident workflows.
Related: Saved View, Trace Annotations
LLM Provider
Section titled “LLM Provider”The service/vendor that hosts a model API (e.g., OpenAI, Anthropic). Providers determine latency, pricing, and capability availability.
The specific LLM identifier used for an execution (e.g., a particular GPT/Claude version). Models affect cost, quality, and risk characteristics.
Related: Provider, Token Usage
Ops Console
Section titled “Ops Console”An operator-focused UI for managing governance: traces, policies, skills, approvals, settings, and exports.
Related: Operations
Provider
Section titled “Provider”The underlying system that serves model inference (vendor or deployment). “Provider” is often used when multiple models are available through one integration.
Related: LLM (Large Language Model)
Saved View
Section titled “Saved View”A user-saved query/filter definition used for quickly returning to trace/audit/dashboard views.
Related: Audit Filter, Dashboard
SSE (Server-Sent Events)
Section titled “SSE (Server-Sent Events)”An HTTP streaming protocol used for real-time updates to clients (e.g., trace created/completed, decision created/resolved).
Related: SSE Fan-out
SSE Fan-out
Section titled “SSE Fan-out”A service that multiplexes event streams from many instances to many clients, enabling fleet-level real-time views.
Related: Fleet Visibility, SSE
Standup
Section titled “Standup”A periodic status report (often daily) summarizing what the agent did, what changed, and what needs attention. Some control plane implementations treat this as a capability flag.
Related: HEARTBEAT.md
Telemetry Ingest
Section titled “Telemetry Ingest”The API flow where adapters send traces/cost/metrics/violations back to governance for storage, auditing, and dashboards.
Related: Adapter Telemetry, Signed Telemetry
Violations
Section titled “Violations”Recorded events where policy, scope, or enforcement constraints were not followed (or were bypassed via override). Violations reduce trust status and trigger alerts.
Related: Trust Status, Alert