Skip to main content
A bridge translates a protocol-specific action (MCP tool call, ROS 2 topic publish, MAVLink command, OPC UA write, etc.) into a unified policy evaluation format. SINT ships twelve.

​
Per-resource state machine

Every bridge runs a per-resource state machine for each topic, service, action, or tool it mediates. 
UNREGISTERED → PENDING_AUTH → AUTHORIZED → ACTIVE → SUSPENDED
     ↑              ↓              ↓          ↓         ↓
     └──────────────┴──────────────┴──────────┴─────────┘
                   (re-authorization flow)
A resource cannot carry data in the SUSPENDED state. Re-authorization requires a fresh token bound to the current session. This allows real-time revocation without a restart.

​
The twelve bridges

bridge-mcp

MCP tool calls with risk classification. Security-enforcing proxy that sits between an AI agent and any number of downstream MCP servers.

bridge-ros2

ROS 2 topics, services, actions with physics extraction. Maps velocity, force, and position to SintCapabilityToken constraints.

bridge-a2a

Google A2A Protocol bridge for multi-agent coordination.

bridge-iot

Generic MQTT/CoAP edge IoT bridge with gateway session interception.

bridge-mqtt-sparkplug

MQTT Sparkplug profile with industrial command-tiering defaults.

bridge-opcua

OPC UA node and method mapping with safety-critical write/call promotion.

bridge-open-rmf

Open-RMF fleet and facility mapping for warehouse dispatch workflows.

bridge-grpc

gRPC service and method profile mapping with default tier assignment.

bridge-mavlink

MAVLink drone and UAV command bridge. Armed-state cross-system policy integration.

bridge-swarm

SwarmCoordinator for multi-robot collective constraints.

bridge-economy

Economy bridge with balance, budget, trust, and billing ports. Cost-aware routing.

bridge-hal

Hardware Abstraction Layer — auto-detect hardware, select deployment profile.

​
Bridge anatomy

Every bridge implements the same interface: 
interface Bridge {
  // Discover resources this bridge mediates
  discover(): Promise<Resource[]>;

  // Convert a transport-specific action to a SintRequest
  translate(rawAction: unknown): Promise<SintRequest>;

  // Enforce the Policy Gateway's decision
  enforce(decision: PolicyDecision, action: unknown): Promise<EnforcementResult>;

  // Per-resource state machine for each mediated endpoint
  getStateMachine(resource: string): ResourceStateMachine;
}
This uniformity is what enables cross-system policies — the gateway sees every bridge’s traffic in the same shape.

​
Cross-system policies

See architecture for the mechanics of cross-system policies. Canonical examples:
PolicyWhen activeDenies
no-fs-while-movingrobot.moving (from bridge-ros2)File writes via bridge-mcp
no-deploy-while-activecmd_vel active (from bridge-ros2)Deploys via bridge-mcp
no-network-while-armeddrone.armed (from bridge-mavlink)Network calls via bridge-mcp
no-reboot-during-surgerypatient.connected (from a custom bridge)System reboot via bridge-mcp

​
Writing a new bridge

1

Implement the Bridge interface

Create packages/bridge-yourprotocol/ with a class implementing discover, translate, enforce, and getStateMachine.
2

Define the resource schema

Map your protocol’s identifiers to SINT resource URIs. E.g. opcua://node/ns=2;i=1234.
3

Add tier defaults

Provide a default tier map — which operations in your protocol are T0/T1/T2/T3 by default.
4

Add conformance tests

Every bridge needs a conformance-test suite in packages/conformance-tests/. See conformance.
5

Document in docs.sint.gg

Add your bridge to this page and a dedicated sub-page at protocol/bridges/yourprotocol.
Community bridges live in sint-ai/sint-bridges-community. If your bridge is generally useful, open a PR to upstream it into the main repo.