loading…
Search for a command to run...
loading…
Security-first MCP governance proxy (sint-mcp) with capability tokens, T0-T3 approval tiers, fail-closed execution, and tamper-evident audit receipts. Includes
Security-first MCP governance proxy (sint-mcp) with capability tokens, T0-T3 approval tiers, fail-closed execution, and tamper-evident audit receipts. Includes a separate sint-scan CLI for preflight MCP tool-risk audits.
Security, permission, and economic enforcement layer for physical AI.
SINT is the missing governance layer between AI agents and the physical world. Every tool call, robot command, and actuator movement flows through a single Policy Gateway that enforces capability-based permissions, graduated approval tiers, and tamper-evident audit logging.
Academic grounding: SINT is designed with reference to IEC 62443 FR1–FR7, EU AI Act Article 13, and NIST AI RMF. The evaluation framework references the ROSClaw empirical safety study (arXiv:2603.26997) and MCP security analysis (arXiv:2601.17549).
Agent ──► SINT Bridge ──► Policy Gateway ──► Allow / Deny / Escalate
│
Evidence Ledger (SHA-256 hash-chained)
│
ProofReceipt (pluggable attestation)
The installable server entrypoint is sint-mcp.
npx -y sint-mcp --stdio
npx -y sint-mcp --config ./sint-mcp.config.example.json --stdio
If you prefer containers, build and run the repo root Dockerfile:
docker build -t sint-mcp .
docker run --rm -i sint-mcp
If you want the fastest builder-facing path into the SEP-1763 interceptor work:
pnpm install
pnpm run build
pnpm run demo:interceptor-quickstart
That walkthrough shows the full flagship loop in one terminal transcript:
allow or escalateStart here:
AI agents can now control robots, execute code, move money, and operate machinery. They can also access your health data, control your smart home, and orchestrate critical infrastructure. But there's no standard security layer between "the LLM decided to do X" and "X happened in the physical world or with your personal data."
| Capability | SINT Protocol | Microsoft AGT | MCP Baseline | SROS2 |
|---|---|---|---|---|
| Physical constraint enforcement (velocity, force, geofence) | ✅ In token | ❌ | ❌ | ❌ |
| Tier-based human oversight (T0–T3) | ✅ 4-tier | ⚠️ Execution rings | ❌ | ❌ |
| Append-only hash-chained audit | ✅ SHA-256 | ⚠️ Logging | ❌ | ❌ |
| ROS 2 / MAVLink / industrial bridges | ✅ 12 bridges | ❌ Digital only | ❌ | ⚠️ ROS only |
| Consumer smart home governance | ✅ Home Assistant + Matter | ❌ | ❌ | ❌ |
| HIPAA + GDPR health data access | ✅ FHIR + HealthKit | ❌ | ❌ | ❌ |
| OWASP ASI01–ASI10 coverage | ✅ 10/10 Full | ✅ 10/10 | ❌ | ❌ |
| Economic routing + budgets | ✅ bridge-economy | ❌ | ❌ | ❌ |
| Swarm collective constraints | ✅ SwarmCoordinator | ❌ | ❌ | ❌ |
| E-stop / CircuitBreaker | ✅ EU AI Act Art. 14 | ✅ Kill switch | ❌ | ❌ |
| Caregiver delegation + consent | ✅ FHIR Consent tokens | ❌ | ❌ | ❌ |
| Differential privacy ledger | ✅ Per-query epsilon budget | ❌ | ❌ | ❌ |
SINT is the only framework purpose-built for physical AI and personal data governance — where actions are irreversible and have real-world consequences. Microsoft AGT targets digital/software agents; SINT targets robots, drones, smart homes, health fabric, and critical infrastructure.
The empirical case for SINT:
Core guarantees:
# Prerequisites: Node.js >= 22, pnpm >= 9
pnpm install
pnpm run build
pnpm run test # full workspace test suite
pnpm --filter @sint/gateway-server dev
# → http://localhost:3100/v1/health
# → http://localhost:3100/v1/ready
# → http://localhost:3100/v1/docs
pnpm run stack:dev
pnpm run stack:edge
pnpm run stack:prod-lite
pnpm run stack:gazebo-validation
pnpm run stack:isaac-sim-validation
Compose profiles:
docs.sint.gg)pnpm run docs:dev
pnpm run docs:build
pnpm run docs:preview
Docs source lives in docs/, VitePress config is in docs/.vitepress/config.mts, and deployment is handled by docs-site.yml.
Community/adoption assets:
pnpm --filter @sint/gate-policy-gateway test
pnpm --filter @sint/bridge-mcp test
SINT extends far beyond industrial robotics. Two major consumer domains now have governance frameworks:
AI agents accessing your smart home go through the Policy Gateway:
import { HAInterceptor } from "@sint/bridge-homeassistant";
const interceptor = new HAInterceptor({
policyGateway,
homeAssistantHost: "homeassistant.local",
});
// Claude says: "unlock the front door"
const result = await interceptor.intercept({
toolName: "call_service",
toolInput: { domain: "lock", service: "unlock", entity_id: "lock.front_door" },
});
// → Escalates to T2_ACT (requires human approval)
// → Evidence Ledger records the decision and outcome
Tier-appropriate defaults:
See packages/bridge-homeassistant and packages/bridge-matter.
Patient data accessed by AI agents goes through consent-based governance:
import { createFHIRConsentToken } from "@sint/bridge-health";
// Patient grants AI agent 7-day read access to health observations
const consentToken = createFHIRConsentToken(
"did:key:patient123", // grantor (patient)
"did:key:aiagent456", // grantee (AI agent)
["Observation", "DiagnosticReport"],
["read"],
new Date(Date.now() + 7 * 24 * 60 * 60 * 1000),
{ scope: "patient-privacy", purposeOfUse: ["TREAT"] }
);
await policyGateway.issueToken(consentToken);
Civil liberties guarantees:
See packages/bridge-health and the consumer smart home integration guide.
A voice-first, HUD-based control surface for SINT operators. Every command flows through the Policy Gateway.
pnpm run stack:interface # starts gateway + interface + postgres + redis
# Opens: http://localhost:3202
Features:
@sint/memory)sint__notify (T2 tier, requires confirmation)See docs/guides/sint-interface.md for full setup and usage.
If you are an AI agent (Claude, GPT, Gemini, Cursor, etc.) working in this repo, read AGENTS.md first. It covers key invariants, common mistakes, and entry points for the most common tasks. For deeper implementation details, see CLAUDE.md.
┌──────────────────────────────────────────────────────────────┐
│ AI Agents / Foundation Models │
│ (Claude, GPT, Gemini, open-source) │
└──────────────────┬───────────────────────────────────────────┘
│
┌──────────────────▼───────────────────────────────────────────┐
│ SINT Bridge Layer (L1) │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌──────────┐ │
│ │ bridge-mcp │ │ bridge-ros2│ │ bridge-a2a │ │ bridge- │ │
│ │ MCP tools │ │ ROS topics │ │ Google A2A │ │ open-rmf │ │
│ └────────────┘ └────────────┘ └────────────┘ └──────────┘ │
│ ┌──────────────────────┐ ┌───────────────────────────────┐ │
│ │ bridge-mqtt-sparkplug│ │ bridge-opcua │ │
│ │ Industrial IoT │ │ PLC / OT control plane bridge │ │
│ └──────────────────────┘ └───────────────────────────────┘ │
│ Per-resource state: UNREGISTERED→PENDING_AUTH→AUTHORIZED │
│ →ACTIVE→SUSPENDED (real-time revocation without restart) │
└──────────────────┬───────────────────────────────────────────┘
│ SintRequest (UUIDv7, Ed25519, resource, action, physicalContext)
┌──────────────────▼───────────────────────────────────────────┐
│ SINT Gate (L2) — THE choke point │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ PolicyGateway.intercept() │ │
│ │ 1. Schema validation (Zod) │ │
│ │ 2. Token validation (Ed25519 + expiry + revocation) │ │
│ │ 3. Resource scope check │ │
│ │ 4. Per-token rate limiting (sliding window) │ │
│ │ 5. Physical constraint enforcement │ │
│ │ 6. Forbidden action sequence detection │ │
│ │ 7. Tier assignment: max(BaseTier, Δ_human, Δ_trust...) │ │
│ │ 8. T2/T3 → escalate to approval queue │ │
│ │ 9. T0/T1 + approved T2/T3 → allow │ │
│ │ 10. Bill via EconomyPlugin (if configured) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ ↓ │
│ EvidenceLedger (SHA-256 hash chain + ProofReceipt) │
└──────────────────────────────────────────────────────────────┘
| APS Concept | SINT Implementation |
|---|---|
| Principal | agentId (Ed25519 public key) + W3C DID identity |
| Capability | SintCapabilityToken (Ed25519-signed, scoped, attenuatable) |
| Authority | PolicyGateway.intercept() — single choke point |
| Confinement | Per-token resource scope + physical constraints (velocity, force, geofence) |
| Revocation | RevocationStore + ConsentPass endpoint (real-time) |
| Audit | EvidenceLedger — append-only, SHA-256 hash-chained |
| Package | Description | Tests |
|---|---|---|
| @sint/core | Types, Zod schemas, tier constants, formal DFA states | — |
| @sint/gate-capability-tokens | Ed25519 tokens, delegation, W3C DID identity | 55 |
| @sint/gate-policy-gateway | Authorization engine: tiers, constraints, rate limiting, M-of-N quorum | 256 |
| @sint/gate-evidence-ledger | SHA-256 hash-chained append-only audit log with pluggable attestation | 45 |
Industrial & Robotics (9)
| Package | Description | Tests |
|---|---|---|
| @sint/bridge-mcp | MCP tool call interception and risk classification | 66 |
| @sint/bridge-ros2 | ROS 2 topic/service/action interception with physics extraction | 20 |
| @sint/bridge-a2a | Google A2A Protocol bridge for multi-agent coordination | 38 |
| @sint/bridge-iot | Generic MQTT/CoAP edge IoT bridge with gateway session interception | 21 |
| @sint/bridge-mqtt-sparkplug | MQTT Sparkplug profile mapping with industrial command tiering defaults | 8 |
| @sint/bridge-opcua | OPC UA node/method mapping with safety-critical write/call promotion | 6 |
| @sint/bridge-open-rmf | Open-RMF fleet/facility mapping for warehouse dispatch workflows | 5 |
| @sint/bridge-grpc | gRPC service/method profile mapping with default tier assignment | 5 |
| @sint/bridge-mavlink | MAVLink drone/UAV command bridge | 15 |
Coordination & Economics (2)
| Package | Description | Tests |
|---|---|---|
| @sint/bridge-economy | Economy bridge: balance, budget, trust, billing ports | 47 |
| @sint/bridge-swarm | Multi-robot swarm coordination bridge | 9 |
Consumer & Health (3) — Phase 1-5 Physical AI Governance
| Package | Description | Tests |
|---|---|---|
| @sint/bridge-homeassistant | Consumer smart home MCP interceptor with device profiles (locks, cameras, alarms, climate, vacuums) — Phase 1 | 36 |
| @sint/bridge-health | FHIR R5 + HealthKit/Health Connect with differential privacy, consent tokens, and caregiver delegation — Phase 5 | — |
| @sint/bridge-matter | Matter protocol bridge for unified smart home device governance — Phase 2 | — |
Note: some consumer/health bridges are currently in “prototype API” state. CI may temporarily skip their build/typecheck/test scripts until their public interfaces are aligned with the @sint/core request/decision model.
Reference Implementation (1)
| Package | Description | Tests |
|---|---|---|
| @sint/sint-pdp-interceptor | Reference SEP-1763 PDP adapter for MCP interceptor hosts backed by PolicyGateway.intercept() |
5 |
| Package | Description | Tests |
|---|---|---|
| @sint/engine-system1 | Neural perception: sensor fusion, ONNX inference, anomaly detection | 42 |
| @sint/engine-system2 | Symbolic reasoning: behavior trees, task planning, System 1/2 arbitration | 86 |
| @sint/engine-hal | Hardware Abstraction Layer: auto-detect hardware, select deployment profile | 26 |
| @sint/engine-capsule-sandbox | WASM/TS capsule loading, validation, and sandboxed execution | 36 |
| @sint/avatar | Avatar Layer (L5): behavioral identity profiles, CSML-driven tier escalation | 25 |
| Package | Description | Tests |
|---|---|---|
| @sint/capsule-navigation | Waypoint following navigation reference capsule | 11 |
| @sint/capsule-inspection | Visual anomaly detection for manufacturing QA | 8 |
| @sint/capsule-pick-and-place | Gripper control for pick-and-place tasks | 12 |
| Package | Description | Tests |
|---|---|---|
| @sint/persistence | Storage interfaces + in-memory/PG/Redis implementations | 26 |
| @sint/persistence-postgres | Production PostgreSQL adapters for ledger, revocation, and rate-limit durability | 14 |
| Package | Description | Tests |
|---|---|---|
| @sint/gateway-server | Hono HTTP API with approvals, SSE streaming, A2A routes | — |
| sint-mcp | Security-first multi-MCP proxy server | — |
| @sint/dashboard | Real-time approval dashboard with operator auth | 29 |
| @sint/client | TypeScript SDK for the Gateway API (delegation, SSE) | — |
| @sint/sdk | Zero-dependency public TypeScript SDK aligned to gateway v0.2 contracts | 9 |
| @sint/conformance-tests | Security regression suite — all phases | — |
Total: 41 workspace members · 1,772 tests passing
Note: Run
pnpm testto get the current exact passing test count.
Graduated authorization mapped to physical consequence severity:
| Tier | Name | DFA States | Auto-approved? | Example |
|---|---|---|---|---|
| T0 | OBSERVE | → OBSERVING | Yes (logged) | Read sensor data, query database |
| T1 | PREPARE | → PREPARING | Yes (audited) | Write file, save waypoint, stage plan |
| T2 | ACT | ESCALATING → ACTING | Requires review | Move robot, operate gripper, publish /cmd_vel |
| T3 | COMMIT | ESCALATING → COMMITTING | Requires human + optional M-of-N | Execute trade, novel environment entry, irreversible action |
Tier escalation triggers (Δ factors):
Δ_human: Human presence sensor active in workspace → +1 tierΔ_trust: Agent trust score below threshold or recent failures → +1 tierΔ_env: Robot near physical boundary or unstructured environment → +1 tierΔ_novelty: Action outside validated distribution (novelty detector) → +1 tierSINT models every request as a deterministic finite automaton with 12 states:
IDLE → PENDING → POLICY_EVAL → PLANNING → OBSERVING/PREPARING/ACTING → COMMITTING → COMPLETED
↓ ↓
ESCALATING ROLLEDBACK (estop, execution failure)
↓
FAILED (approval denied, timeout)
The ACTING state is only reachable via POLICY_EVAL with a valid token. Physical actuation is structurally impossible without a valid capability token.
Tier(r) = max(BaseTier(r), Δ_human(r), Δ_trust(r), Δ_env(r), Δ_novelty(r))
| Invariant | Description |
|---|---|
| I-T1 (Attenuation) | scope(child_token) ⊆ scope(parent_token) — delegation can only reduce permissions |
| I-T2 (Unforgeability) | Capability tokens are Ed25519-signed; valid tokens are computationally unforgeable |
| I-T3 (Physical Constraint Primacy) | Physical constraints (velocity, force, geofence) in a token cannot be weakened by any downstream layer |
| I-G1 (No Bypass) | Physical actuation is only reachable from the ACTING DFA state, which is only reachable via POLICY_EVAL |
| I-G2 (E-stop Universality) | The estop event transitions any non-terminal state to ROLLEDBACK unconditionally |
| I-G3 (Ledger Primacy) | COMMITTING → COMPLETED requires ledger_committed; no action completes without a ledger record |
PolicyGateway latency (measured on M3 MacBook Pro, pnpm run bench):
| Tier | p50 | p99 |
|---|---|---|
| T0 (OBSERVE) | ~1ms | ~3ms |
| T1 (PREPARE) | ~1ms | ~3ms |
| T2 (ACT) | ~1ms | ~3ms |
| T3 (COMMIT) | ~1ms | ~3ms |
The gateway adds sub-3ms overhead at p99 for all tiers. Run benchmarks: pnpm run bench.
ROS2 control-loop target benchmark:
| Path | SLA Target | Command |
|---|---|---|
ROS2 command path (/cmd_vel) |
p99 < 10ms |
pnpm run benchmark:ros2-loop |
Industrial benchmark artifacts:
Compliance mapping assets:
Ed25519-signed capability tokens — the only authorization primitive. Unlike RBAC (ambient authority to principals), OCap requires explicit token presentation for every operation.
Token fields:
ros2:///cmd_vel, mcp://filesystem/*, a2a://agents.example.com/*)publish, call, subscribe, a2a.send)did:key:z6Mk... format for agent portabilityEvery policy decision is recorded in a SHA-256 hash-chained append-only log. Chain integrity: ℓ_k.previousHash = SHA256(canonical(ℓ_{k-1})). A gap or hash mismatch constitutes tamper evidence.
For portable verification across bridges and external tooling, SINT now routes receipt and tool-definition signing through a shared deterministic canonical JSON serializer instead of relying on insertion-order-sensitive JSON.stringify() behavior.
For strong-tier flows, SINT can emit a linked bilateral receipt pair: a gate receipt before execution is allowed to proceed and a completion receipt once execution settles. The pair shares a stable actionRef and linkageHash so auditors can verify both authorization and outcome as one governed action.
Retention policy:
| Tier | Retention |
|---|---|
| T0 (OBSERVE) | 30 days |
| T1 (PREPARE) | 90 days |
| T2 (ACT) | 180 days |
| T3 (COMMIT) | 365 days (indefinite if legal hold) |
A deployment metric that fuses behavioral and physical safety dimensions:
CSML(m, p, t) = α·AR_m + β·BP_m + γ·SV_m - δ·CR_m + ε·𝟙[ledger_intact(t)]
CSML above a deployment threshold θ automatically escalates all subsequent requests from that model backend to the next tier.
| FR | Title | SINT Mechanism |
|---|---|---|
| FR1 | Identification & Authentication | SintCapabilityToken with Ed25519 agent identity; W3C DID portability |
| FR2 | Use Control | Four-tier Approval Gate; maxRepetitions constraint; per-resource action allowlists |
| FR3 | System Integrity | SHA-256 hash-chained Evidence Ledger; ProofReceipt for T2/T3 (TEE attestation planned) |
| FR4 | Data Confidentiality | Zenoh TLS transport; capability scope prevents sensor access without explicit token |
| FR5 | Restricted Data Flow | Policy Gateway allowlists; geofence constraint; SINT Bridge per-topic DFA |
| FR6 | Timely Response | safety.estop.triggered event; E-stop universality invariant I-G2 |
| FR7 | Resource Availability | Per-token rate limiting; maxRepetitions; budget enforcement in capsule sandbox |
| Requirement | SINT Approach |
|---|---|
| Logging and traceability | SHA-256 hash-chained Evidence Ledger — tamper detection is cryptographic |
| Human oversight | Dynamic Consent + T3 approval gate — T3 actions cannot execute without recorded human approval |
| Risk management | Tier escalation based on real-time physical context (Δ_human, Δ_env, Δ_novelty) |
| SINT Tier | NIST AI RMF | ISO/IEC 42001 | EU AI Act |
|---|---|---|---|
| T0 Observe | MAP + MEASURE + MANAGE monitoring controls | Clause 9 + Clause 8 controls | Article 12 + Article 13 |
| T1 Prepare | GOVERN + MANAGE controlled write path | Clause 8.1/8.2 operational risk treatment | Article 9 + Article 12 |
| T2 Act | MANAGE risk response with accountable oversight | Clause 8 + Clause 6 operational controls | Article 14 + Article 15 |
| T3 Commit | Highest-consequence GOVERN + MANAGE controls | Clause 8.3 + Clause 10 corrective governance | Article 14(4)(e) + Articles 9/12/15 |
Machine-readable crosswalk endpoint: GET /v1/compliance/tier-crosswalk
| Method | Endpoint | Description |
|---|---|---|
GET |
/.well-known/sint.json |
Public protocol discovery (version, bridges, profiles, schemas) |
GET |
/v1/health |
Health check |
POST |
/v1/intercept |
Evaluate a single request |
POST |
/v1/intercept/batch |
Evaluate multiple requests (207 Multi-Status) |
POST |
/v1/tokens |
Issue a capability token |
POST |
/v1/tokens/delegate |
Delegate (attenuate) a token |
POST |
/v1/tokens/revoke |
Revoke a token |
GET |
/v1/ledger |
Query audit ledger events |
GET |
/v1/approvals/pending |
List pending approval requests |
POST |
/v1/approvals/:id/resolve |
Approve or deny a request (M-of-N quorum) |
GET |
/v1/approvals/events |
SSE stream for real-time approval events |
GET |
/v1/approvals/ws |
WebSocket stream for low-latency approval events |
POST |
/v1/a2a |
JSON-RPC 2.0 A2A protocol endpoint |
GET |
/v1/metrics |
Prometheus metrics |
GET |
/v1/openapi.json |
OpenAPI surface for gateway integration |
GET |
/v1/compliance/tier-crosswalk |
SINT tier mapping to NIST AI RMF / ISO 42001 / EU AI Act controls |
POST |
/v1/economy/route |
Cost-aware route selection with optional x402 pay-per-call quotes |
| Phase | Description | Tests |
|---|---|---|
| Phase 1 (complete) | Security Wedge — capability tokens, PolicyGateway, EvidenceLedger | 425 |
| Phase 2 (complete) | Engine Core — bridge-mcp, bridge-ros2, engine packages, persistence, gateway-server | +221 (646) |
| Phase 3 (complete) | Economy Bridge — @sint/bridge-economy with port/adapter pattern, EconomyPlugin | +91 (737) |
| Phase 4 (complete) | Standards Alignment — A2A bridge, rate limiting, M-of-N quorum, W3C DID identity | +78 |
| Phase 5 (complete) | Protocol Surface v0.2 — discovery/OpenAPI/schema endpoints, industrial profiles | shipped |
| Phase 6 (complete) | Engine layer — System1/2 engines, HAL, capsule sandbox, Avatar/CSML, reference capsules | shipped |
Extending SINT to consumer, health, and critical infrastructure domains:
| Phase | Focus | Status | Examples |
|---|---|---|---|
| Phase 1 | Consumer Smart Home (Q2–Q3 2026) | ✅ Complete | bridge-homeassistant — Home Assistant MCP interceptor with 12 device classes (locks, cameras, alarms, climate, robot vacuums). Tier-appropriate defaults: locks/alarms→T2, lights/climate→T1, cameras→T0. |
| Phase 2 | Matter Protocol Unification (Q3–Q4 2026) | ✅ Complete | bridge-matter — Unified smart home governance across Matter-certified devices. Device discovery, service profiles, and tier assignment. |
| Phase 3 | Occupancy & Human Presence (2027) | 📋 Planned | Δ_human plugin: escalate robot vacuums to T2 when occupancy detected. Build on Phase 1 sensor fusion. |
| Phase 4 | Critical Infrastructure (2027–2028) | 📋 Planned | Power grids, water systems, industrial facilities. Formalized risk models and emergency-mode escalation. |
| Phase 5 | Health Fabric & Wellbeing (Q4 2026–Q1 2027) | ✅ Complete | bridge-health — FHIR R5 consent governance, HealthKit/Health Connect on-device processing, differential privacy ledger, and caregiver delegation tokens. HIPAA + GDPR alignment. |
See docs/roadmaps/PHYSICAL_AI_GOVERNANCE_2026-2029.md for full roadmap.
brew install railway
railway login
./scripts/railway-setup.sh
railway variables --set SINT_STORE=postgres SINT_CACHE=redis SINT_API_KEY=$(openssl rand -hex 32)
railway up
docker-compose up
# Gateway: http://localhost:3100
# Dashboard: http://localhost:3201
# Postgres: localhost:5432
# Redis: localhost:6379
pnpm test for current count)Physical AI Governance (Consumer, Health, Critical Infrastructure)
PolicyGateway.intercept(); no bridge adapter makes authorization decisions independently| Feature | Status | Target |
|---|---|---|
| npm package publishing (8 core packages) | 🔧 In progress | April 2026 |
| Python SDK (PyNaCl + Pydantic) | 🔧 In progress | April 2026 |
| Production gateway deployment | 📋 Planned | April 2026 |
| Getting Started tutorial | ✅ Complete | docs/getting-started.md |
| TEE proof receipts (Intel SGX / ARM TrustZone) | 📋 Planned | Q2 2026 |
| Hardware-in-the-loop ROS 2 testing | 📋 Planned | Q2 2026 |
| Formal verification (TLA+ / Alloy) | 📋 Planned | Q3 2026 |
| Domain | Phase | Status | Roadmap |
|---|---|---|---|
| Consumer Smart Home | 1–2 | ✅ Complete | PHYSICAL_AI_GOVERNANCE_2026-2029.md |
| Health & Wellbeing | 5 | ✅ Complete | FHIR R5, HealthKit, caregiver delegation, differential privacy |
| Critical Infrastructure | 4 | 📋 Planned | Power grids, water systems, industrial facilities (2027–2028) |
| Occupancy & Human Presence | 3 | 📋 Planned | Δ_human sensors, smart vacuums, physical boundaries (2027) |
Apache-2.0
Добавь это в claude_desktop_config.json и перезапусти Claude Desktop.
{
"mcpServers": {
"sint-ai-sint-protocol": {
"command": "npx",
"args": []
}
}
}Web content fetching and conversion for efficient LLM usage.
Retrieval from AWS Knowledge Base using Bedrock Agent Runtime.
Provides auto-configuration for setting up an MCP server in Spring Boot applications.
A very streamlined mcp client that supports calling and monitoring stdio/sse/streamableHttp, and can also view request responses through the /logs page. It also