Morphism Technical Documentation

assetactive

Provenance

Ingested from C:\Users\mesha\Downloads\morphism-technical-documentation.md on 2026-03-28. Original file ~46KB. Full content included below.


Morphism: Technical Documentation

Policy & Governance Layer for Production AI Agents


Table of Contents

  1. Conceptual Foundation
  2. System Architecture
  3. Core Abstractions
  4. Feature Reference
  5. Policy Specification Language
  6. Runtime Enforcement Model
  7. Audit & Observability
  8. Integration Patterns
  9. Operational Controls
  10. Security Model

1. Conceptual Foundation

Category-Theoretic Framing

Morphism derives its name and its architecture from a precise analogy in category theory. Understanding this framing clarifies every design decision downstream.

In category theory, a morphism is a structure-preserving map between two objects in a category. It does not destroy the objects it connects — it relates them, transforming inputs to outputs while respecting the rules of the category they inhabit.

Formally, given a category C:

Objects:    A, B ∈ Ob(C)
Morphism:   f : A → B
Identity:   id_A : A → A
Composition: g ∘ f : A → C  (where f : A → B, g : B → C)

The key properties are:

  • Identity: Every object has an identity morphism — an agent left unmodified by governance still produces valid output
  • Composability: Morphisms compose — policies layer without breaking each other
  • Structure preservation: The map respects the underlying structure — Morphism does not rewrite agent behavior, it constrains the space of permitted transitions

Application to Agent Governance

An AI agent operating in production can be modeled as a functor — a mapping between categories:

Agent:  Context_Category → Action_Category

Where:

  • Context_Category contains objects representing world states, memory states, and input tokens
  • Action_Category contains objects representing tool calls, API invocations, outputs, and side effects

Morphism inserts itself as a natural transformation — a systematic, structure-preserving way to constrain which morphisms in Action_Category the agent is permitted to reach:

η : Agent → PolicyConstrained(Agent)

This is not prompt engineering. It is not an output filter. It is a transformation of the agent's reachable action space at runtime, applied consistently, with the same structural guarantees at every point of composition.

Why This Matters Architecturally

The category-theoretic framing produces three concrete architectural consequences:

| Theoretical Property | Architectural Consequence | |---|---| | Composability of morphisms | Policies layer and combine without mutual interference | | Functoriality | Framework-agnostic enforcement — the functor structure is preserved regardless of what orchestration layer the agent uses | | Natural transformations commute | Policy enforcement is consistent across parallel agent runs — enforcement at point A and enforcement at point B yield the same constraints |


2. System Architecture

High-Level Topology

┌─────────────────────────────────────────────────────────────────────┐
│                        Your Existing Stack                          │
│                                                                     │
│   ┌──────────────┐      ┌──────────────┐      ┌──────────────┐     │
│   │  LangChain   │      │  LlamaIndex  │      │   AutoGen    │     │
│   │  LlamaIndex  │      │   AutoGen    │      │   Custom     │     │
│   └──────┬───────┘      └──────┬───────┘      └──────┬───────┘     │
│          │                     │                      │             │
└──────────┼─────────────────────┼──────────────────────┼────────────┘
           │                     │                      │
           ▼                     ▼                      ▼
┌─────────────────────────────────────────────────────────────────────┐
│                     MORPHISM GATEWAY LAYER                          │
│                                                                     │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌───────────┐ │
│  │   Policy    │  │  Runtime    │  │    Audit    │  │   Kill    │ │
│  │   Engine    │  │  Enforcer   │  │   Logger    │  │  Switch   │ │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘  └─────┬─────┘ │
│         │                │                 │               │        │
│  ┌──────▼────────────────▼─────────────────▼───────────────▼─────┐ │
│  │                    Core Event Bus                              │ │
│  └────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
           │                     │                      │
           ▼                     ▼                      ▼
┌─────────────────────────────────────────────────────────────────────┐
│                     TOOL & API SURFACE                              │
│                                                                     │
│   ┌──────────────┐      ┌──────────────┐      ┌──────────────┐     │
│   │  Databases   │      │ External APIs│      │  File System │     │
│   │  Data Stores │      │  LLM Calls   │      │  Messaging   │     │
│   └──────────────┘      └──────────────┘      └──────────────┘     │
└─────────────────────────────────────────────────────────────────────┘

Internal Component Architecture

┌────────────────────────── MORPHISM CORE ──────────────────────────┐
│                                                                    │
│  ┌─────────────────────────────────────────────────────────────┐  │
│  │                    POLICY STORE                             │  │
│  │                                                             │  │
│  │  Git Repository ──► Policy Compiler ──► Compiled Policy     │  │
│  │  (YAML source)       (validation +      (binary AST,        │  │
│  │                       type checking)     versioned)         │  │
│  └─────────────────────────────┬───────────────────────────────┘  │
│                                │                                   │
│                                ▼                                   │
│  ┌─────────────────────────────────────────────────────────────┐  │
│  │                   POLICY ENGINE                             │  │
│  │                                                             │  │
│  │  Policy Loader ──► Rule Evaluator ──► Decision Renderer     │  │
│  │  (version-aware)   (predicate eval,   (ALLOW / DENY /       │  │
│  │                     context-aware)     REQUIRE_APPROVAL)    │  │
│  └─────────────────────────────┬───────────────────────────────┘  │
│                                │                                   │
│                    ┌───────────┴────────────┐                      │
│                    ▼                        ▼                      │
│  ┌──────────────────────┐    ┌──────────────────────────────────┐  │
│  │   RUNTIME ENFORCER   │    │         AUDIT ENGINE             │  │
│  │                      │    │                                  │  │
│  │  Intercept           │    │  Event Capture                   │  │
│  │  → Evaluate          │    │  → Structured Logging            │  │
│  │  → Allow / Block     │    │  → Tamper-evident Chain          │  │
│  │  → Emit event        │    │  → Export (SIEM, S3, etc.)       │  │
│  └──────────┬───────────┘    └──────────────────────────────────┘  │
│             │                                                       │
│             ▼                                                       │
│  ┌──────────────────────────────────────────────────────────────┐  │
│  │                  CONTROL PLANE                               │  │
│  │                                                              │  │
│  │  Kill Switch ──► Agent Registry ──► Health Monitor           │  │
│  │  (hard stops)    (per-agent state)   (lifecycle tracking)    │  │
│  └──────────────────────────────────────────────────────────────┘  │
│                                                                    │
└────────────────────────────────────────────────────────────────────┘

Data Flow: Single Agent Action Request

Agent decides to call a tool
         │
         ▼
┌─────────────────────┐
│  Action Intent      │  ← Agent constructs action payload
│  Constructed        │
└────────┬────────────┘
         │
         ▼
┌─────────────────────┐
│  Morphism           │  ← Intercept layer captures intent
│  Intercept Point    │    before execution
└────────┬────────────┘
         │
         ▼
┌─────────────────────┐
│  Context            │  ← Enriches action with: agent ID,
│  Enrichment         │    session ID, policy version, timestamp,
│                     │    parent action chain
└────────┬────────────┘
         │
         ▼
┌─────────────────────┐
│  Policy             │  ← Evaluates all applicable rules
│  Evaluation         │    in precedence order
└────────┬────────────┘
         │
    ┌────┴──────────────────────────────┐
    │                                   │
    ▼                                   ▼
ALLOW                               DENY / REQUIRE_APPROVAL
    │                                   │
    ▼                                   ▼
┌──────────────┐               ┌──────────────────────┐
│ Execute tool │               │ Block execution      │
│ call         │               │ Emit audit event     │
│              │               │ Return structured    │
│              │               │ error to agent       │
└──────┬───────┘               └──────────────────────┘
       │
       ▼
┌──────────────┐
│ Capture      │
│ result +     │
│ emit audit   │
│ event        │
└──────────────┘

3. Core Abstractions

Morphism is built on six primitive abstractions. All features compose from these.

3.1 Agent

An Agent in Morphism is any process that makes decisions and executes actions via tools or APIs. Morphism is identity-agnostic about what runs the agent — it treats the agent as a black box that emits action intents.

Agent := {
  id:          UUID,
  name:        String,
  version:     SemVer,
  policy_set:  PolicySet.ref,
  session:     Session.ref,
  parent:      Agent.ref | null   // for sub-agent hierarchies
}

3.2 Action

An Action is any intent to affect state — a tool call, an API call, a read, a write, a message send.

Action := {
  id:           UUID,
  type:         ActionType,       // TOOL_CALL | API_CALL | FILE_IO | LLM_CALL | ...
  agent:        Agent.ref,
  target:       Resource,
  parameters:   Map<String, Any>,
  context:      ExecutionContext,
  timestamp:    ISO8601,
  parent_action: Action.ref | null
}

3.3 Policy

A Policy is a named, versioned set of rules that map action predicates to decisions.

Policy := {
  id:       UUID,
  name:     String,
  version:  SemVer,
  rules:    [Rule],              // evaluated in order
  scope:    Scope,               // which agents this policy applies to
  priority: Integer              // tie-breaking between policy sets
}

3.4 Rule

A Rule is a single predicate-decision pair.

Rule := {
  id:         UUID,
  predicate:  Predicate,         // expression that matches actions
  decision:   Decision,          // ALLOW | DENY | REQUIRE_APPROVAL | RATE_LIMIT
  effect:     Effect,            // what to do beyond the decision
  metadata:   RuleMetadata       // author, rationale, linked ticket
}

3.5 Decision

A Decision is the output of policy evaluation for a given action.

Decision := ALLOW
          | DENY(reason: String)
          | REQUIRE_APPROVAL(approver: ApproverSet, timeout: Duration)
          | RATE_LIMITED(retry_after: Duration)
          | QUARANTINE(escalation: EscalationPolicy)

3.6 Audit Event

An Audit Event is the immutable record of every policy evaluation.

AuditEvent := {
  id:             UUID,
  action:         Action,
  policy_version: SemVer,
  rules_matched:  [Rule.ref],
  decision:       Decision,
  execution_ms:   Integer,
  chain_hash:     SHA256,        // hash of prior event — tamper-evident chain
  timestamp:      ISO8601
}

4. Feature Reference

4.1 Policies in Git (GitOps Policy Management)

Policies are YAML files committed to a Git repository. Morphism treats Git as the source of truth for all policy state.

Workflow:

Author edits policy YAML
         │
         ▼
Pull request opened
         │
         ▼
Morphism CI check runs
  - Schema validation
  - Logic conflict detection
  - Coverage analysis (are any agent actions now unaddressed?)
  - Diff against current production policy
         │
         ▼
Review + approval
         │
         ▼
Merge to main
         │
         ▼
Morphism policy sync triggered (webhook or pull interval)
         │
         ▼
Policy compiled and distributed to all enforcement nodes
         │
         ▼
Previous policy version archived (not deleted)

Guarantees provided:

  • Full history of every policy change with author and rationale
  • Rollback to any prior version in one command
  • No policy drift between environments — environment-specific overrides are explicit, not implicit
  • Policy reviews are part of standard engineering workflow, not a separate security process

4.2 Runtime Enforcement

Morphism enforces policies before execution — not as a logging layer after the fact.

Enforcement modes:

| Mode | Description | Use Case | |---|---|---| | BLOCKING | Action is not executed if denied | Production enforcement | | SHADOW | Action executes, but policy decision is computed and logged | Policy testing before enforcement | | ADVISORY | Action executes, violation emits alert but does not block | Gradual rollout | | DRY_RUN | Policy evaluated against historical action logs, no live traffic | Policy authoring and validation |

Enforcement points available:

┌────────────────────────────────────────────────────────────────┐
│  ENFORCEMENT POINTS                                            │
│                                                                │
│  1. Pre-tool-call         ← Before any tool is invoked        │
│  2. Pre-LLM-call          ← Before tokens are sent to model   │
│  3. Pre-API-call          ← Before external HTTP requests      │
│  4. Pre-file-write        ← Before filesystem mutations        │
│  5. Pre-database-write    ← Before any DB mutation             │
│  6. Pre-message-send      ← Before any outbound message        │
│  7. Post-tool-result      ← After result received, before use  │
│  8. Post-LLM-response     ← After response, before processing  │
│  9. Agent-spawn           ← Before a sub-agent is created      │
│  10. Agent-join           ← Before sub-agent results consumed  │
└────────────────────────────────────────────────────────────────┘

4.3 Audit Trails

Every action — allowed or denied — produces a structured, tamper-evident audit event.

Properties of the audit log:

  • Completeness: Every action intent is captured, not just violations
  • Tamper evidence: Each event includes a hash of the prior event, forming a cryptographic chain
  • Reconstructibility: Any agent session can be fully replayed from the audit log alone
  • Structured schema: Events are machine-readable, not log lines — queryable by action type, agent, policy, time range, decision
  • Retention policies: Configurable per environment, with export to SIEM, S3, Splunk, Datadog, or custom sinks

Audit event structure (expanded):

audit_event:
  id: "evt_01H9X..."
  timestamp: "2024-11-15T14:23:01.442Z"
  
  agent:
    id: "agent_billing_reconciler"
    version: "1.4.2"
    session_id: "sess_01H9X..."
    parent_agent: null
  
  action:
    id: "act_01H9X..."
    type: "API_CALL"
    target:
      service: "stripe"
      endpoint: "/v1/refunds"
      method: "POST"
    parameters:
      amount: 4900
      charge_id: "ch_abc123"
    parent_action: "act_01H9X...parent"
  
  policy_evaluation:
    policy_version: "2.1.0"
    rules_evaluated: 7
    rules_matched:
      - rule_id: "rule_stripe_refund_limit"
        decision: DENY
        reason: "Refund amount 4900 exceeds per-session limit of 2500"
    final_decision: DENY
    evaluation_ms: 3
  
  chain:
    prior_event_id: "evt_01H9X...prior"
    prior_event_hash: "sha256:a3f9..."
    this_event_hash: "sha256:b7c2..."

4.4 Kill Switch

The kill switch provides immediate, guaranteed termination of in-flight agent sessions.

Kill switch levels:

Level 1: PAUSE
  - Suspend pending actions
  - In-flight actions complete
  - Agent waits for resume signal
  - Use case: Unexpected behavior, need to investigate without data loss

Level 2: STOP
  - No new actions accepted
  - In-flight actions complete
  - Session terminated cleanly
  - Use case: Planned shutdown, soft incident response

Level 3: TERMINATE
  - Immediate halt
  - In-flight actions cancelled where possible
  - Rollback hooks triggered
  - Use case: Active incident, clear harm being done

Level 4: QUARANTINE
  - Immediate halt
  - Agent state frozen and preserved for forensics
  - All outputs to downstream systems blocked
  - Incident automatically opened
  - Use case: Security incident, compliance breach

Kill switch targeting:

Target:  Single agent session          (by session_id)
         All sessions of an agent      (by agent_id)
         All agents in a policy scope  (by policy_scope)
         All agents platform-wide      (global kill)

Invocation methods:

  • CLI: morphism agent kill --session sess_01H9X... --level TERMINATE
  • API: POST /v1/agents/{session_id}/kill
  • Dashboard: one-click per session or global
  • Webhook trigger: automated response to alert conditions
  • PagerDuty / OpsGenie integration: kill switch as runbook action

4.5 Policy Scoping and Hierarchy

Policies apply to agents through a scope hierarchy. More specific scopes override less specific ones unless the less specific policy is marked enforced.

Platform Scope
  └── Environment Scope (prod / staging / dev)
        └── Team Scope (billing-team / ml-team)
              └── Agent Type Scope (reconciler / summarizer)
                    └── Agent Instance Scope (specific agent_id)

Inheritance rules:

inheritance:
  mode: "merge"          # merge | override | additive
  conflict_resolution: "most_restrictive"   # most_restrictive | explicit_priority

4.6 Rate Limiting and Quota Enforcement

Beyond allow/deny, Morphism enforces rate limits and resource quotas as first-class policy decisions.

Configurable dimensions:

rate_limits:
  - dimension: "api_calls_per_minute"
    limit: 60
    window: "1m"
    scope: "per_agent_session"
    
  - dimension: "llm_tokens_per_hour"
    limit: 500000
    window: "1h"
    scope: "per_agent_type"
    
  - dimension: "external_spend_usd_per_day"
    limit: 100.00
    window: "24h"
    scope: "per_team"
    reset: "00:00 UTC"

Behaviors on limit breach:

  • Soft limit: advisory alert, action proceeds
  • Hard limit: action blocked, retry-after header returned to agent
  • Escalating limit: first breach advisory, second breach block, third breach quarantine

4.7 Approval Workflows

For high-risk actions, Morphism can pause an agent and require human approval before continuing.

Agent requests high-risk action
         │
         ▼
Policy returns REQUIRE_APPROVAL
         │
         ▼
Agent session pauses (action not executed)
         │
         ▼
Approval request sent to:
  - Slack (with action context, approve/deny buttons)
  - Email
  - PagerDuty
  - Custom webhook
         │
         ▼
Approver reviews action context + audit trail
         │
    ┌────┴────┐
    │         │
  APPROVE   DENY
    │         │
    ▼         ▼
Agent     Action blocked,
resumes   error returned,
          audit event written

Timeout handling:

approval_policy:
  timeout: "15m"
  on_timeout: "DENY"    # DENY | ESCALATE | ALLOW (not recommended for prod)
  escalation_chain:
    - approver: "on-call-engineer"
      after: "5m"
    - approver: "engineering-lead"
      after: "10m"

4.8 Policy Testing and Simulation

Before promoting a policy to production, Morphism provides a testing framework.

Test types:

# policy_test.yaml

policy_tests:
  - name: "Stripe refund limit enforced"
    action:
      type: API_CALL
      target:
        service: stripe
        endpoint: /v1/refunds
      parameters:
        amount: 9999
    expected_decision: DENY
    expected_rule: "rule_stripe_refund_limit"

  - name: "Small refund allowed"
    action:
      type: API_CALL
      target:
        service: stripe
        endpoint: /v1/refunds
      parameters:
        amount: 500
    expected_decision: ALLOW

Simulation against historical traffic:

morphism policy simulate \
  --policy ./policies/billing-agent-v2.yaml \
  --against-audit-log "2024-11-01..2024-11-15" \
  --agent billing-reconciler \
  --report diff

Output shows: how many historical actions would have been decided differently, which rules would have triggered, projected coverage and gap analysis.

4.9 Agent Dependency and Lineage Tracking

In multi-agent systems, Morphism tracks the full call graph of agent invocations.

Root Agent (task_orchestrator)
  │
  ├── Sub-agent A (data_fetcher)
  │     └── Sub-agent A1 (db_query_executor)
  │
  └── Sub-agent B (report_writer)
        └── Sub-agent B1 (external_sender)

Every audit event carries its full lineage chain. Policies can be written that reference lineage:

rules:
  - name: "External sends only from verified lineage"
    predicate:
      action_type: API_CALL
      target_service: sendgrid
    condition:
      lineage_includes: "report_writer"
      root_agent: "task_orchestrator"
    decision: ALLOW

  - name: "Block external sends from unknown lineage"
    predicate:
      action_type: API_CALL
      target_service: sendgrid
    decision: DENY

4.10 Schema and Parameter Validation

Beyond allow/deny on action type, Morphism validates the parameters of every action against declared schemas.

rules:
  - name: "Validate refund parameters"
    predicate:
      action_type: API_CALL
      target_service: stripe
      endpoint: /v1/refunds
    parameter_schema:
      amount:
        type: integer
        minimum: 1
        maximum: 2500
      currency:
        type: string
        enum: ["usd", "eur", "gbp"]
      reason:
        type: string
        required: true
    on_schema_violation: DENY

4.11 Secret and Data Classification Enforcement

Morphism can enforce data handling policies — preventing agents from passing sensitive data classes to unvetted endpoints.

data_classification:
  rules:
    - name: "PII must not leave approved services"
      predicate:
        contains_data_class: PII
        target_service:
          not_in: ["internal-crm", "data-warehouse"]
      decision: DENY
      
    - name: "API keys must not appear in LLM prompts"
      predicate:
        action_type: LLM_CALL
        parameter_pattern:
          prompt:
            matches_pattern: "(sk-|Bearer |api_key=)"
      decision: DENY
      effect:
        alert: security-team
        severity: HIGH

5. Policy Specification Language

Structure of a Policy File

# morphism-policy.yaml

apiVersion: morphism/v1
kind: Policy

metadata:
  name: billing-agent-production
  version: 2.1.0
  description: >
    Governs all actions taken by the billing reconciliation agent
    in the production environment.
  authors:
    - name: "Jane Smith"
      team: platform-engineering
  linked_tickets:
    - "INFRA-4821"
    - "SEC-112"
  tags:
    - billing
    - production
    - pci-adjacent

scope:
  environments: [production]
  agent_types: [billing-reconciler]
  agent_ids: []        # empty = all instances of the type

inheritance:
  from: platform-baseline
  mode: merge
  conflict_resolution: most_restrictive

enforcement_mode: BLOCKING

rules:

  - id: rule_allow_read_operations
    name: "Allow all read operations"
    priority: 100
    predicate:
      action_type: [API_CALL, DB_QUERY]
      method: [GET, SELECT]
    decision: ALLOW

  - id: rule_stripe_refund_limit
    name: "Cap refund amounts per session"
    priority: 200
    predicate:
      action_type: API_CALL
      target_service: stripe
      endpoint: "/v1/refunds"
      method: POST
    conditions:
      - field: "parameters.amount"
        operator: "greater_than"
        value: 2500
    decision: DENY
    reason: "Refund exceeds per-session safety cap of $25.00"
    effect:
      alert:
        channel: "#billing-alerts"
        severity: MEDIUM

  - id: rule_large_refund_approval
    name: "Require approval for refunds 10-25 USD"
    priority: 190
    predicate:
      action_type: API_CALL
      target_service: stripe
      endpoint: "/v1/refunds"
      method: POST
    conditions:
      - field: "parameters.amount"
        operator: "between"
        value: [1000, 2500]
    decision: REQUIRE_APPROVAL
    approval:
      approvers: ["billing-lead", "on-call-engineer"]
      timeout: "10m"
      on_timeout: DENY

  - id: rule_block_production_deletes
    name: "Block all DELETE operations in production"
    priority: 10
    predicate:
      action_type: [API_CALL, DB_MUTATION]
      method: [DELETE, DROP, TRUNCATE]
    decision: DENY
    reason: "Destructive operations require manual execution in production"
    effect:
      alert:
        channel: "#security-incidents"
        severity: HIGH
      kill_switch:
        level: PAUSE
        auto_resume: false

rate_limits:
  - id: rl_stripe_calls
    dimension: calls_per_minute
    target_service: stripe
    limit: 20
    window: 1m
    on_breach: BLOCK

  - id: rl_llm_tokens
    dimension: tokens_per_hour
    limit: 100000
    window: 1h
    on_breach: ADVISORY

audit:
  level: FULL              # FULL | DECISIONS_ONLY | VIOLATIONS_ONLY
  export:
    - sink: s3
      bucket: morphism-audit-prod
      prefix: billing-agent/
    - sink: splunk
      index: morphism-prod

6. Runtime Enforcement Model

Enforcement Pipeline

Incoming Action Intent
        │
        ▼
┌───────────────────┐
│  1. Deserialize   │  Parse action payload, validate structure
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  2. Contextualize │  Attach agent identity, session, lineage,
│                   │  environment, timestamp, correlation IDs
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  3. Classify      │  Determine action type, target service,
│                   │  data classes present, parameter schema
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  4. Resolve       │  Determine which policies apply
│     Policy Set    │  (scope hierarchy, inheritance, version)
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  5. Evaluate      │  Apply rules in priority order
│     Rules         │  Short-circuit on first definitive match
│                   │  unless full evaluation required for audit
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  6. Check Rate    │  Evaluate rate limit and quota state
│     Limits        │  against distributed counter store
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  7. Render        │  Produce final Decision
│     Decision      │  (ALLOW / DENY / REQUIRE_APPROVAL / etc.)
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  8. Write Audit   │  Write immutable event before acting on
│     Event         │  the decision — audit is never skipped
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  9. Execute or    │  Allow: pass through to tool
│     Block         │  Deny: return structured error
│                   │  Approval: pause session, notify
└───────────────────┘

Latency Budget

Morphism is designed for sub-10ms policy evaluation in the common case:

| Step | Target Latency | |---|---| | Deserialize + Contextualize | < 0.5ms | | Policy set resolution | < 0.5ms (cached) | | Rule evaluation | < 2ms (compiled policy AST) | | Rate limit check | < 1ms (in-memory counter) | | Audit event write | < 2ms (async, non-blocking) | | Total | < 5ms p99 |

Policy compilation happens at deploy time, not at runtime. Evaluation is against a compiled binary representation, not interpreted YAML.


7. Audit & Observability

Audit Trail Architecture

┌──────────────────────────────────────────────────────────────────┐
│                      AUDIT ENGINE                                │
│                                                                  │
│  ┌───────────────┐    ┌─────────────────┐    ┌───────────────┐  │
│  │  Event        │    │  Chain          │    │  Storage      │  │
│  │  Capture      │───►│  Commitment     │───►│  Writer       │  │
│  │               │    │  (hash linking) │    │               │  │
│  └───────────────┘    └─────────────────┘    └───────┬───────┘  │
│                                                       │          │
│                              ┌────────────────────────┤          │
│                              │                        │          │
│                    ┌─────────▼──────┐    ┌────────────▼───────┐  │
│                    │  Primary       │    │  Export Sinks      │  │
│                    │  Store         │    │  (SIEM / S3 / etc) │  │
│                    │  (queryable)   │    │                    │  │
│                    └───────┬────────┘    └────────────────────┘  │
│                            │                                     │
│                    ┌───────▼────────┐                            │
│                    │  Query API     │                            │
│                    │  + Replay      │                            │
│                    │    Engine      │                            │
│                    └────────────────┘                            │
└──────────────────────────────────────────────────────────────────┘

Query Interface

# All denied actions in the last 24 hours
morphism audit query \
  --decision DENY \
  --since "24h" \
  --format table

# Full session replay
morphism audit replay --session sess_01H9X...

# Actions by a specific agent that touched Stripe
morphism audit query \
  --agent billing-reconciler \
  --target-service stripe \
  --since "7d" \
  --format json | jq '.[] | select(.action.parameters.amount > 1000)'

# Export for compliance review
morphism audit export \
  --since "2024-11-01" \
  --until "2024-11-30" \
  --format csv \
  --output ./audit-nov-2024.csv

Dashboard Surfaces

  • Real-time feed: live stream of agent actions and decisions
  • Violation heatmap: which agents, which rules, at what frequency
  • Session explorer: drill into any session, see full action tree
  • Policy coverage: which action types have no applicable rules (gaps)
  • Rate limit pressure: current consumption vs. limits per agent and team
  • Approval queue: pending approvals with context, one-click approve/deny

8. Integration Patterns

Pattern 1: Middleware Wrapper (LangChain)

from morphism import MorphismClient, enforce

client = MorphismClient(
    api_key=os.environ["MORPHISM_API_KEY"],
    policy_set="billing-agent-production",
    agent_id="billing-reconciler",
    agent_version="1.4.2"
)

# Wrap any tool with enforcement
@enforce(client)
def call_stripe_refund(amount: int, charge_id: str) -> dict:
    return stripe.Refund.create(amount=amount, charge=charge_id)

# Wrap LangChain tool list
tools = client.wrap_tools([
    StripeRefundTool(),
    DatabaseQueryTool(),
    EmailSenderTool()
])

agent = initialize_agent(tools, llm, agent=AgentType.OPENAI_FUNCTIONS)

Pattern 2: Proxy Interception (Framework-Agnostic)

from morphism import MorphismProxy

# Route all HTTP calls through Morphism proxy
proxy = MorphismProxy(
    policy_set="billing-agent-production",
    agent_id="billing-reconciler"
)

# Replace httpx/requests client
http_client = proxy.http_client()

# All requests now evaluated against policy before sending
response = http_client.post(
    "https://api.stripe.com/v1/refunds",
    data={"amount": 500, "charge": "ch_abc123"}
)

Pattern 3: Sidecar Deployment (Kubernetes)

# k8s pod spec
spec:
  containers:
    - name: billing-agent
      image: company/billing-agent:1.4.2
      env:
        - name: MORPHISM_SIDECAR_URL
          value: "http://localhost:8181"
    
    - name: morphism-sidecar
      image: morphismhq/sidecar:latest
      ports:
        - containerPort: 8181
      env:
        - name: MORPHISM_API_KEY
          valueFrom:
            secretKeyRef:
              name: morphism-credentials
              key: api-key
        - name: MORPHISM_POLICY_SET
          value: "billing-agent-production"
        - name: MORPHISM_AGENT_ID
          value: "billing-reconciler"

Pattern 4: CI/CD Policy Gate

# .github/workflows/deploy-agent.yaml

- name: Validate Morphism Policies
  run: |
    morphism policy validate ./policies/
    morphism policy test ./policies/ --test-suite ./policy-tests/
    morphism policy simulate \
      --policy ./policies/billing-agent-v2.yaml \
      --against-audit-log "7d" \
      --agent billing-reconciler \
      --fail-on-regression

- name: Promote Policy to Production
  if: github.ref == 'refs/heads/main'
  run: |
    morphism policy promote \
      --policy ./policies/billing-agent-v2.yaml \
      --environment production \
      --confirm

9. Operational Controls

Control Plane API (Summary)

| Method | Endpoint | Description | |---|---|---| | GET | /v1/agents | List all registered agents | | GET | /v1/agents/{id}/sessions | List active sessions | | POST | /v1/agents/{session}/kill | Issue kill switch | | GET | /v1/policies | List all policy versions | | POST | /v1/policies | Deploy new policy version | | POST | /v1/policies/simulate | Run simulation against audit log | | GET | /v1/audit/events | Query audit events | | GET | /v1/audit/sessions/{id}/replay | Replay session | | GET | /v1/health | System health | | GET | /v1/metrics | Prometheus-compatible metrics |

CLI Reference (Summary)

# Policy management
morphism policy validate <path>
morphism policy test <path> --test-suite <path>
morphism policy promote <path> --environment <env>
morphism policy rollback --to-version <semver> --environment <env>
morphism policy diff --from <version> --to <version>

# Agent control
morphism agent list
morphism agent sessions --agent <id>
morphism agent kill --session <id> --level <level>
morphism agent quarantine --session <id>

# Audit
morphism audit query [flags]
morphism audit replay --session <id>
morphism audit export [flags]

# Simulation
morphism policy simulate --policy <path> --against-audit-log <range>

10. Security Model

Trust Boundary

Morphism operates as a trusted intermediary between agents and their tools. The security model requires:

  • Agent cannot bypass Morphism — tool access is routed through enforcement, not exposed directly to agent
  • Morphism cannot be manipulated by agent output — policy evaluation is not influenced by agent-generated content
  • Policies are controlled by humans — no agent can modify its own policy set at runtime

Threat Model Coverage

| Threat | Morphism Control | |---|---| | Agent calls unauthorized API | Runtime enforcement blocks before execution | | Agent exfiltrates PII | Data classification rules deny matching calls | | Prompt injection causes harmful action | Action-level enforcement independent of prompt content | | Runaway agent exhausts resources | Rate limiting and quota enforcement | | Agent spawns unauthorized sub-agents | Agent-spawn enforcement point | | Audit log tampered with | Tamper-evident hash chain, export to immutable sink | | Policy changed without review | All policy changes through Git, no out-of-band modification | | Compromised agent causes harm before detection | Kill switch, quarantine, real-time alerting |

Cryptographic Audit Chain

Each audit event commits to the prior event's hash:

event_0 → hash_0
event_1 → hash_1 = SHA256(event_1_content + hash_0)
event_2 → hash_2 = SHA256(event_2_content + hash_1)
...
event_n → hash_n = SHA256(event_n_content + hash_{n-1})

Any modification of a historical event invalidates all subsequent hashes, making tampering detectable by any party with read access to the log.


Summary: Morphism in One Diagram

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│   POLICY SOURCE                CONTROL PLANE                    │
│   Git Repository    ──────►   Policy Engine                     │
│   (YAML policies)             Kill Switch                       │
│   CI/CD validation            Approval Queue                    │
│                               Agent Registry                    │
│                                    │                            │
│                                    ▼                            │
│ ┌──────────────────────────────────────────────────────────┐   │
│ │              MORPHISM ENFORCEMENT LAYER                  │   │
│ │                                                          │   │
│ │  Intercept → Contextualize → Evaluate → Decide → Audit   │   │
│ │                                                          │   │
│ └──────────────────────────────────────────────────────────┘   │
│          ▲                                      │               │
│          │                                      ▼               │
│   AGENT (any framework)               AUDIT ENGINE              │
│   LangChain / AutoGen /               Tamper-evident log        │
│   LlamaIndex / custom                 Query + Replay API        │
│          │                            Export to SIEM / S3       │
│          │                                                       │
│          ▼                                                       │
│   TOOLS + APIS                                                  │
│   (only reachable through Morphism)                             │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Morphism gives platform and engineering teams a single, composable, auditable governance layer for every AI agent they run — without requiring agents to be rewritten, without replacing existing orchestration, and without trading enforcement for observability or observability for control.