Prava Loom is an in-tenant agent that authors, custodies, and heals the connections your AI agents need — Snowflake, Entra-protected APIs, SuccessFactors, on-prem SQL, internal MCP servers, the API a contractor built in 2014. Describe the system in plain language; Loom probes it, works out how it authenticates, test-connects, and writes the connector. A person deposits the secret and approves go-live — the only two steps a human must take — and Loom keeps the connection alive from then on.
Self-hosted: one container beside your gateway · on-prem · air-gapped · local modelSee Loom inside Prava EAG — the control plane above the request path ›
describe
A person in the console, or an agent at the MCP front door, asks in plain language — any language
author
Loom probes the endpoint, infers the auth flow, drafts the connector, and test-connects — it never invents an endpoint
approve
A human deposits the secret out of band and reviews the manifest before go-live; no grant is ever autonomous
heal
Dead sessions re-handshaked, expiring credentials flagged, faults escalated — every transition journaled
Gateways route traffic. Catalogs sell menus. Loom is the third thing: the agent that builds the connector that isn't on the menu, keeps its secrets where they belong, and nurses it for life.
Endpoint, tenant, an API-doc link, "we use Entra" — Loom takes what the person knows, probes the rest, proposes the auth mechanism from evidence (a 401 means a token; an open 200 means none), and emits a working, registered connector.
Secrets live in your vault or environment and enter the registry only as references — env://, keychain://, akv://. Only the deterministic runtime resolves a value, in memory, at connection-open.
A scheduled loop watches every connection: re-handshakes dead sessions, flags credentials approaching rotation, escalates repeated failures to the owner — and never widens its own scope to "try harder".
No secret value ever enters model context, logs, journal, database, or error output. It is structural, not policy: the model's tool surface has no read-secret call, and every output path passes the redaction layer.
The model proposes; the deterministic runtime and a human execute. A new credential, a scope expansion, a go-live — each blocks on explicit approval, with the manifest shown as YAML and in plain English first.
Loom is itself an MCP server. A consuming agent calls request_connection or describe_need, gets back the human steps that remain, and polls connection_status until the route is live. Deposit and approval have no agent-reachable surface.
Point your gateway's agents at one question: "can anyone here do X?" If a live tool already serves the intent, they get it. If not, a governed build request opens — and the agent is told to check again soon.
Loom adopts every system already live in your gateway — the ones it never built — and watches them through the gateway's own health verdicts. A system an operator disables is paused, not paged.
When the requester has an intent but no URL, Loom offers a human-vetted shortlist of 8 well-known public APIs (currency, weather, zip, holiday, …) to pick from. No web scraping, no internet access, zero injection surface.
Authoring runs on a local model through Ollama — no frontier API required, so it works air-gapped. Frontier APIs are a pluggable option, never a dependency. Every authoring run is captured as a secret-free trace that stays in your tenant.
Inside Prava EAG, Loom acts as a registered agent — id loom — under the same ceiling as any other agent, with a scoped machine credential that reaches only the control-plane endpoints it needs. The agent that builds your connectors appears in your audit trail like everyone else.
Intent is journaled write-ahead, before the action. Authored, opened, healed, paused, approved, denied, revoked — every transition is a row that cannot be updated or deleted. "Which agent had access to what, when" is a query, not an investigation.
One container beside your gateway. Nothing leaves your tenant — not the secrets, not the traces, not the model calls.
In the gateway console's Onboarding tab, or from any agent at Loom's MCP front door: "I need a system for our billing API." Loom asks only for what it still needs — the address, how it authenticates — and never guesses.
It probes the endpoint, reads the evidence (status, challenge headers, content type), proposes the auth flow — no auth (public APIs), workload identity, certificate / key-pair and more — drafts the connector, and test-connects. The result is a reviewable manifest, not a black box.
Deposit the secret through the out-of-band intake Loom never reads. Then review the manifest — raw YAML with a syntax check, plus a plain-English reading — and approve go-live. That is the whole human workload.
The manifest lands in your gateway, the tool appears in its catalog, and the heal loop takes over — for this connection and for every system your gateway already served.
Gateways enforce identity at request time. Catalogs sell the popular head of the distribution. iPaaS owns the legacy budget. The long tail — custom instances, internal APIs, on-prem — is where enterprise integration money actually goes.
| MCP gateways | Connector catalogs | iPaaS | Prava Loom | |
|---|---|---|---|---|
| Route and enforce identity | ✓ Core | Partial | Partial | Via the gateway it drives |
| Pre-built popular connectors | ✗ | ✓ Core | ✓ | Consumes them where they exist |
| Author the long-tail connector from human input | ✗ | ✗ | Services engagement | ✓ Core |
| Secrets by reference, in your vault | Partial | Vendor-side | Vendor-side | ✓ Core — rule zero |
| Autonomous lifecycle healing | ✗ | ✗ | ✗ | ✓ Core |
| Embedded in your tenant, zero egress | ✗ | Rarely | On-prem legacy | ✓ Core |
Gateways route. Catalogs sell menus. We ship the agent that builds your 109th connector — inside your tenant — and keeps every connection alive.
Every control below was a design commitment before code, because none of them can be bolted on afterwards. Loom is shaped for your security team's review, not fussed into passing it.
Loom is a control plane. It drives your data plane through a thin per-gateway adapter and borrows that gateway's console as its human surface — Loom ships no UI of its own, on purpose.
The flagship. EAG ships with Build · Watch · Heal built in, powered by Loom: one install, one console, one SKU. The Onboarding tab is Loom's face; approvals live where EAG's approvals already live. See Prava EAG →
Committed to another Gateway? Loom runs as a second container in the same stack and writes routes into your gateway through its adapter. EAG's adapter is first-class and ships first; others follow demand.
Data plane and control plane never share a process. The authoring brain and the secret intake are kept away from the traffic path — a blast-radius boundary your reviewers will recognise, and the reason the standalone motion exists.
When it ships, every install will start with a trial — every feature unlocked.