← All docs

Core concepts

The five things you need to understand to use Cisora well.

Agent

A named unit that calls tools or models.

Identified by a stable agentName string. Cisora auto-creates an inventory entry the first time it sees an action from a new agent. Each agent gets its own risk score, policy scope, and Slack channel routing.

Naming convention: use kebab-case, descriptive — customer-support-bot, devops-deployer, billing-fraud-detector. Avoid reusing one name for multiple logical agents.

Action

A single thing an agent did.

Four types: tool_call (e.g. send_email), model_call (LLM invocation), credential_use (API key fetched from secrets), external_api (third-party HTTP call).

Every action is stored immutably with inputs, outputs (truncated at 8KB), duration_ms, cost_usd, the decision (allow/block/review), and any policy that fired.

Policy

A rule that gates an action inline.

JSON DSL — no code. Policies can allow, block (refuses the action with an error), or review (queues for human approval). Sub-50ms p99 decision latency.

See the full DSL reference →

Incident

A finding from the anomaly detector.

Background Claude analyzer runs every 5 minutes per org, classifies suspicious agent behaviour into OWASP Agentic Top 10 categories: goal_hijack, tool_misuse, identity_abuse, cost_anomaly, rogue_agent, data_leak, prompt_injection.

Severities: critical, high, medium, low. Critical/high fire Slack alerts. All open incidents appear on the Overview dashboard.

Fail-open vs fail-closed

What happens when Cisora is unreachable.

Fail-open (default): if our service is down, your agent continues unaffected. Events are dropped on the floor rather than blocking. Right for almost everyone.

Fail-closed: set failOpen: false in the SDK if you'd rather block than let an action go un-monitored. Right for high-risk environments (finance, healthcare PHI).