Skip to main content

Runtime Safety for Multi-Agent Deployments

Runtime guardrails that enforce safety boundaries without blocking legitimate agent activity. MAREF provides the only open-source runtime governance system with formal verification.

What is multi-agent runtime safety?

Multi-agent runtime safety is the set of controls that govern agent behavior during execution — not just at deployment time. While static safety measures (prompt engineering, tool whitelists, capability registries) set initial boundaries, runtime safety enforces those boundaries dynamically as agents interact with tools, data, and each other.

Runtime safety must handle scenarios that static analysis cannot predict: an agent receiving a cleverly crafted input that causes it to attempt an unauthorized action, one agent's compromised state spreading to others through inter-agent messages, or a model update that subtly changes decision-making boundaries.

MAREF's runtime safety system addresses all of these with identity isolation, real-time decision gates, circuit breakers, and continuous drift monitoring.

How does MAREF prevent agents from exceeding their authority?

MAREF enforces a zero-trust permission model at the agent level. Every agent has a cryptographically signed agent card that declares its capabilities, permitted tools, trust level, and communication boundaries. Before any action is executed, the runtime safety gate verifies:

  • Does the action match the agent's declared capabilities?
  • Is the target tool in the agent's permission matrix?
  • Is the agent's trust state above the minimum required for this action type?
  • Does this action trigger any active safety rules or governance policies?
  • Has the circuit breaker been tripped for this agent or action type?

This multi-layer check happens in under 50ms per action, with 97% of decisions automated through the four-level safety decision tree (Rule → Mode → SafetyGate → Human-in-the-loop escalation).

What happens when an agent fails a safety check?

Failure handling follows a graduated escalation model:

  1. Warning — First failure logs the event and alerts the agent. No action taken.
  2. Sanction — Second failure within the time window downgrades the agent's trust state, reducing its autonomous capabilities.
  3. Isolation — Third failure triggers agent isolation. The agent can no longer communicate with other agents or execute tool calls. Only human intervention can release it.
  4. HALT — Three consecutive failures of the same type trigger the HALT absorbing state. The governance engine locks, requiring authenticated human override to resume.

This four-phase governance model (warning → sanction → isolation → recovery) is configurable per deployment, including custom phase durations and escalation criteria.

How does MAREF isolate agents from each other?

MAREF implements SubAgent isolation, inspired by Git Worktree architecture. Each agent operates in an isolated context with its own memory space, capability registry, and trust state. Cross-agent communication requires explicit handoff through the AgentHandoffProtocol, which verifies the sender's identity, the receiver's permission to accept messages, and the chain of custody for the entire conversation history.

This isolation model prevents prompt injection from spreading across agents. Even if one agent is compromised, the blast radius is limited to that agent's isolated context — neighboring agents remain unaffected.

SubAgent isolation example
from maref import SubAgent, AgentHandoffProtocol

research_agent = SubAgent(
    id="researcher-01",
    context_isolation=True,
    max_handoffs=3
)
code_agent = SubAgent(
    id="coder-01",
    context_isolation=True
)

# Each agent has its own memory, capabilities, and trust state
# Cross-agent calls require signed handoff protocol
result = await research_agent.handoff(
    target=code_agent,
    task="Implement the verification function",
    handoff_chain=[research_agent.id]
)

How does MAREF detect model drift at runtime?

MAREF implements dual-mode drift detection: LoRA weight analysis and ontology embedding comparison. Both run continuously during agent operation.

  • LoRA drift detection — Monitors the distribution of LoRA adapter weights during inference. Shifts in weight distribution can indicate model degradation, concept drift, or adversarial manipulation.
  • Ontology drift detection — Embedds agent outputs into a semantic ontology space and tracks the distribution over time. Changes in output semantics can indicate that the model's understanding has shifted.
  • Triple divergence metrics — Both modes use KL divergence, JS divergence, and Hellinger distance as independent measurements. Only when at least two metrics agree on a significant shift is drift reported.

When drift is detected, the system escalates to a human operator with a detailed report including the divergence values, affected agent IDs, and recommended actions (re-calibrate, rollback model version, or quarantine).

What is the blast radius control system?

The Blast Radius Controller monitors and limits the impact of any single agent failure. It tracks: which agents can influence which other agents, which capabilities are shared vs isolated, the dependency graph of agent-to-agent trust relationships, and the cumulative risk score of each agent based on its access level and recent behavior.

If an agent's blast radius exceeds its configured threshold, the controller automatically tightens constraints — reducing the agent's communication scope, requiring HITL approval for its actions, or isolating it entirely. This prevents failures from cascading through the multi-agent system.

How do I add runtime safety to an existing agent deployment?

MAREF's runtime safety gate integrates as a middleware layer. Add it to your existing LangGraph, CrewAI, or AutoGen deployment without modifying agent logic:

Safety gate middleware integration
from maref import SafetyGateV2

# Wrap your existing orchestrator
safety = SafetyGateV2(
    permission_matrix=my_permissions,
    circuit_breaker=CircuitBreaker(threshold=3),
    drift_detector=DriftDetector()
)

# Intercept agent actions before they reach tools
for action in agent_actions:
    decision = await safety.check(action)
    if decision.allowed:
        await execute(action)
    else:
        await safety.escalate(
            action,
            reason=decision.reason,
            severity=decision.severity
        )

For a complete walkthrough, see the Quickstart guide. For governance fundamentals, see Agent Governance.

Runtime Safety Specifications

Safety model
Zero-trust per-agent with capability isolation
Decision latency
<50ms per action (97% automated)
Escalation phases
4: Warning → Sanction → Isolation → HALT
Drift detection
LoRA weight + Ontology embedding, triple divergence metrics
Agent isolation
SubAgent context isolation (Git Worktree-style)
Cross-framework
LangGraph, CrewAI, AutoGen, Dify, Coze
Communication
A2A v0.3 + MCP dual protocol, signed handoff chain