Core Concepts

The Governance Loop

ABS Core operates on a continuous loop applied to every agent action:

1. Intercept: Capture the intent before the action reaches any external system
2. Evaluate: Run CHI drift check, OCS pre-flight, and Policy Engine verdict
3. Enforce: Execute the verdict — ALLOW, DENY, HOLD, or SLASH
4. Prove: Hash the full decision envelope into the forensic ledger — with optional Polygon L2 anchoring in Enterprise tier

The key principle: interception happens before execution, not after. ABS Core is not an observability tool that tells you what happened. It is an enforcement runtime that determines what is allowed to happen.

Platform Pillars

The following core pillars are co-deployed as a single runtime. None operates in isolation.

1. CHI — Cognitive Host Interface

Forces intent declaration before action. Detects semantic drift, PII leakage, and prompt injection. See CHI documentation.

2. QUORUM — Consensus Gate

Requires M-of-N signatures (human or agent) for sensitive actions, ensuring decentralized governance.

3. MCP Bridge — Tool Governance

Secure gateway for Model Context Protocol. Enforces policies on third-party tool interactions.

4. L2 Forensic Ledger

Cryptographically anchored record of every kernel verdict. Immutable and publicly verifiable.

5. AICCP — Change Control

Structured decision cycles (ADRs) required for all irreversible state mutations.

6. OCS — Offline Sentinel

Runs entirely in-process to block regulatory (LGPD/PCI) or budget violations before network egress.

7. CORTEX — Cognitive Monitoring

Analyzes intent drift and maintains reputation scores for all workflow participants.

8. Policy DSL — Rule Engine

Declarative YAML-based governance syntax for environment and operation control.

9. IaC Guard — Infrastructure Vaccine

Prevents unauthorized mutations to cloud resources (S3, IAM, VPC) at the intent level.

Key Components

# Magic Proxy handles interception at the edge
base_url = "https://api.abscore.app/v1"

Claude Code Integration

Claude Code is a high-autonomy agent runtime that executes commands, write code, and manages repositories. ABS Core acts as a biological immune system for this infrastructure, injecting 3 Core Vaccines into the agent's execution environment:

• Command Interception: Prevents destructive shell commands (e.g., rm -rf /) through real-time policy evaluation.
• Safety Overrides: Automatically injects "Safety Vaccines" into the agent's context to prevent jailbreaking or policy bypass.
• Audit Trails: Every action performed via Claude Code is hashed and anchored in the Forensic Ledger.

CORTEX: Cognitive Monitoring & Reputation

CORTEX provides deep observability into the cognitive "mental state" of your agents. It doesn't just log raw actions; it analyzes intent, detects semantic drift, and maintains a reputation score for every participant (human or agent) in the workflow. High-risk intents trigger immediate quarantine, while historical reliability scores inform future quorum requirements.

MCP Bridge: Extended Toolsets

The Model Context Protocol (MCP) Bridge allows ABS Core to govern tools and data sources that aren't natively supported. By acting as a secure gateway for MCP servers, the Bridge ensures that even third-party capabilities follow your strict local policies without requiring SDK modifications.

The IaC Guard is the specialized engine for infrastructure-as-code (IaC) and cloud resource governance. It intercepts mutation intent at the resource level:

• Resource Prototyping: Ensures all requested infrastructure (IAM roles, S3 buckets, VPCs) follows approved architectural blueprints.
• Shadow IT Prevention: Identifies and blocks unauthorized cloud resource creation before the provider's API is even reached.
• Intent-Level Blocking: Evaluates the meaning of the infrastructure change, preventing misconfigurations that lead to data exposure.

Sentinel SDK

Native TypeScript and Python instrumentation for deep governance. Required for complex agent topologies. Provides abs.check(), abs.log(), abs.startHeartbeat(), and CHI envelope construction helpers.

Policy Contracts

Versioned YAML documents that define what each agent is and is not allowed to do. Every contract is identified by its SHA-256 hash. Contracts are evaluated atomically — a partial match produces a DENY, never a partial allow.

agent_id: payment-agent-01
version: "2.1.0"
rules:
  - action: transfer_funds
    conditions:
      max_amount: 10000
      require_chi_level: high
      destination_whitelist: ["account-*-internal"]
    verdict: ALLOW
  - action: "*"
    verdict: DENY

Decision Envelope

Every verdict produced by the policy engine is wrapped in a Decision Envelope (ADR-008):

• event_id — UUID v4, used as idempotency key
• agent_id — the governed agent
• verdict — ALLOW, DENY, HOLD, or SLASH
• rule_id — the specific policy rule that matched
• chi_summary — hash of the CHIAnalysis envelope
• policy_version_hash — hash of the policy contract active at decision time
• kernel_signature — ECDSA signature from the governance kernel
• prev_hash — SHA-256 of the previous ledger entry (Merkle chain)
• timestamp — ISO 8601, millisecond precision

The Decision Envelope is the unit of proof. It is what gets anchored in the forensic ledger — and optionally on Polygon L2 in Enterprise deployments.

Forensic Ledger

Append-only, hash-chained audit trail. Each entry contains the full Decision Envelope plus the hash of the previous entry. Modifying any entry invalidates all subsequent hashes — tamper evidence is structural, not dependent on access controls.

The forensic ledger maintains a SHA-256 hash chain locally in Cloudflare Durable Objects. Enterprise tier includes optional anchoring on Polygon L2 via the AuditEmitter contract — enabling independent verification by regulators and counterparties without trusting ABS Core.

Bond and Slash

Financial collateral mechanism for high-stakes agent deployments. An agent with a bond has financial skin in the game — policy violations trigger automatic fund deduction (slashing) proportional to the breach severity.

• POST /v1/agents/:agentId/bond — stake collateral
• Slashing activates on SLASH verdict from the policy engine
• Slash events are included in the immutable ledger with amount, rule, and timestamp

Decision Quorum (M-of-N)

For actions identified as "High Risk" by the policy engine (e.g., large financial transfers, destructive infrastructure changes), ABS Core can trigger a Decision Quorum.

The action is placed on HOLD until a consensus of M-of-N responders is achieved. Responders can be:

• Human Administrators: Requesting explicit approval via Slack or Management Console.
• Multi-Agent Verification: Requiring a secondary safety agent to cross-verify the intent and risk profile.
• Hybrid Quorum: A combination of automated safety agents and human final oversight.

No critical action is executed without the quorum-signed receipt anchoring the consensus in the ledger.

Trust Hierarchy

Policies are applied in layers, from highest to lowest priority:

1. Kernel Layer — Immutable invariants compiled into the WASM binary (e.g., "never expose private keys in any output")
2. Platform Layer — ABS Core-managed rules (e.g., LGPD compliance defaults)
3. Profile Layer — Domain-specific rules per deployment (e.g., Financial, Healthcare)
4. Workspace Layer — Team-specific rules (e.g., dev environment allow-lists)

A rule at a higher layer cannot be overridden by a rule at a lower layer.

Agent Identity

ABS Core must identify the agent for stateful policy evaluation (velocity limits, bond status, reputation). Identity resolution priority:

1. Explicit agent_id in request metadata — highest accuracy, required for multi-agent setups
2. Auth token extracted from Authorization header
3. IP hash — fallback only, not reliable for multi-tenant or NAT environments

Always provide explicit agent_id in production deployments.

Event Idempotency

Every event carries a UUID v4 event_id. The kernel enforces exactly-once processing:

1. On receipt, check decision_logs for an existing entry with the same event_id
2. If found, return the stored decision — no re-evaluation
3. If not found, evaluate and write with event_id as the unique key

The idempotency window is the full retention period (default: 90 days). This prevents duplicate audit entries when agents or load balancers retry requests.

Entropy and Semantic Intent

Two real-time analysis techniques run on every payload before the policy engine evaluates it:

Shannon Entropy: Measures information density. High entropy (>4.5 bits/char) suggests obfuscated content — base64 tunnels, encrypted payloads, steganographic injection. Triggers a HIGH_ENTROPY flag for the policy engine.

Semantic Intent Classification: A small language model runs locally to classify the action's purpose (data retrieval, financial transaction, deletion, credential access). This classification is compared against the agent's allowed action types in its policy contract. This is separate from and complementary to CHI's intent declaration — CHI is agent-declared, semantic classification is independently assessed.