One sentence. Three connectors. Policy enforcement at every level.
See exactly how ContextWeaver processes this request — from AI Hub to Stripe charge to email confirmation.
That's it. You don't click through screens. You don't open a travel website. You don't open your credit card app. You don't write an email. You just say what you want.
In any company, different people have different spending limits. Your company probably has rules like:
A manager uploads these rules from any data source — documents, web pages, wikis, databases, or even pasted text. Each source is chunked, vectorized, and indexed for semantic search. No coding required. The AI searches these indexes before every action and enforces them automatically.
RAG stands for Retrieval-Augmented Generation. Sounds fancy. Here's what it really means:
Think of it like a smart filing cabinet. Your company's rules are filed away. Before the AI does anything, it opens the cabinet, reads the relevant rules, and follows them.
The magic: the rules come from any data source — documents, web pages, wikis, databases, blob storage. Each source is chunked, embedded into vectors, and stored in searchable AI indexes. Change the source, and the AI's behavior changes instantly. No developers needed. No code deployments.
The AI needs to log into Stripe to charge your card, and into Gmail to send your email. But different people have different accounts. How does it know which one to use?
It checks your personal vault first. If you haven't set up your own key, it checks your team's. If your team hasn't set one up either, it uses the company default. Like a waterfall — it flows down until it finds what it needs.
When you say "Book a flight and charge my Amex", here's what happens in about 5 seconds:
One sentence in. Flight booked, card charged, email sent, calendar updated. Rules followed. No screens. No forms.
Every box below is a real component running in ContextWeaver. Follow the arrows to see how a single sentence becomes a booked flight.
alice@acme.com • Group: Engineering • Role: developer_user_email=alice@acme.com from every request → per-user credential resolutioncw-org-cw-payments-secret-key → Org Stripe keycw-grp-engineering-cw-payments-secret-key → Eng Stripe keycw-pvt-alice-cw-email-app-password → Alice’s Gmailcw-payments-policy-org → "Max $5000/month"cw-payments-policy-engineering → "Max $500/purchase"prefs-alice → "Prefer Amex, aisle seat"search_all(query="travel purchase policy flight booking")
travel-proxy-call(tool="search_flights", args={from:"BOS", to:"NYC", class:"economy"})
payments-charge(amount=189, card="amex", description="Delta DL2847 BOS-JFK")
email-send(to="alice@acme.com", subject="Flight Booked: BOS→JFK", body="...")email-calendar-create(title="Flight BOS→JFK", date="2026-05-01 08:00")
Three people say the same thing. ContextWeaver enforces different policies for each.
| Connector | Alice (Eng) | Bob (Sales) | Carol (Eng/Intern) |
|---|---|---|---|
| Stripe Key | 🏢 Org key (no override) | 👥 Sales group key | 🏢 Org key (no override) |
| Travel API | 🏢 Org key | 🏢 Org key | 🏢 Org key |
| Email/Gmail | 👤 Alice’s Gmail | 👤 Bob’s Outlook | 👤 Carol’s Gmail |
| Policy (RAG) | Org + Eng rules + prefs | Org + Sales rules + prefs | Org + Eng + Intern rules |
Here is exactly what happens on the wire when Alice types "Book a flight BOS to NYC and charge my Amex". Every HTTP call, every vault lookup, every database query — in order.
| 1 | Browser → Keycloak | POST /realms/contextweaver/protocol/openid-connect/token |
Alice logs in via SSO (OIDC). Gets JWT access token. |
| 2 | Browser → Cerebro App | GET /api/user/identity + Authorization: Bearer eyJ... |
App validates JWT, extracts: email=alice@acme.com, groups=[engineering], roles=[developer] |
| 3 | Cerebro App → MCP Engine | POST /api/set-user + {"email":"alice@acme.com","groups":["engineering"]} |
Syncs user identity to the MCP engine so tool calls know who is calling |
| 4 | Agent → MCP Engine | POST /mcp (Streamable HTTP) + X-User-Email: alice@acme.com{"method":"tools/list"} |
Discovers all 33 tools from 4 plugins. Returns tool names, descriptions, parameter schemas. |
| 5 | Agent → MCP Engine | {"method":"resources/list"} |
Discovers available knowledge indexes for RAG search |
| 6 | Agent → Engine Dashboard | GET /api/plugins |
Fetches system_prompt from each plugin manifest — policy enforcement instructions injected into LLM context |
| 7 | Agent → Azure OpenAI | POST /openai/deployments/gpt-4o/chat/completionsSystem prompt includes: 33 tool definitions + policy enforcement rules + available indexes |
LLM reads the prompt, decides: "I should check policies first, then search flights" |
| 8 | LLM returns tool call | {"tool":"search_all","args":{"query":"travel flight purchase policy"}} |
LLM tells Agent to search knowledge indexes for policies |
| 9 | Agent → MCP Engine | POST /mcp + {"method":"tools/call","params":{"name":"search_all","arguments":{"query":"travel flight purchase policy","_user_email":"alice@acme.com"}}} |
Agent injects _user_email into every tool call for per-user resolution |
| 10 | MCP Engine → Azure AI Search | POST /indexes/cw-payments-policy-org/docs/searchPOST /indexes/cw-payments-policy-engineering/docs/searchPOST /indexes/prefs-a1b2c3d4e5f6/docs/search |
Vector search across 3 scoped indexes. Results tagged: [ORG_POLICY], [GROUP_POLICY], [USER_PREFERENCE] |
| 11 | Results returned to LLM | ORG: "Max $5000/mo, economy only" • GROUP: "Engineering max $500/flight" • USER: "Prefer Delta, Amex, aisle" | LLM now knows: must be economy, under $500, prefer Delta |
| 12 | Agent → MCP Engine | tools/call: travel-proxy-call(tool="search_flights", args={from:"BOS",to:"NYC",class:"economy"}) |
LLM constrained search to economy (org policy) |
| 13 | MCP Engine → Vault | vault.read("cw-pvt-{alice-hash}-cw-travel-proxy-upstream-url") → missvault.read("cw-grp-engineering-cw-travel-proxy-upstream-url") → missvault.read("cw-org-cw-travel-proxy-upstream-url") → hit! |
Credential cascade: tries user, then group, then org. Finds org-level travel API config. |
| 14 | MCP Engine → Travel API | POST https://travel-api.example.com/mcp + Bearer token from vault |
Calls upstream travel MCP server with resolved credentials |
| 15 | Agent → MCP Engine | tools/call: payments-charge(amount=189, card="amex", description="Delta DL2847 BOS-JFK") |
LLM validated: $189 < $500 group limit ✅ |
| 16 | MCP Engine → Vault | vault.read("cw-pvt-{alice}-cw-payments-secret-key") → missvault.read("cw-grp-engineering-cw-payments-secret-key") → missvault.read("cw-org-cw-payments-secret-key") → hit! sk_test_... |
Resolves Stripe API key via cascade |
| 17 | MCP Engine → Vault (private) | vault.read("cw-pvt-{alice}-cw-payments-stripe-customer-id") → cus_abc123 |
Gets Alice’s personal Stripe Customer ID (created on first charge) |
| 18 | MCP Engine → Stripe API | GET https://api.stripe.com/v1/payment_methods?customer=cus_abc123&type=card |
Lists Alice’s saved cards, finds AMEX ****1005 |
| 19 | MCP Engine → Stripe API | POST https://api.stripe.com/v1/payment_intentsamount=18900, currency=usd, customer=cus_abc123, payment_method=pm_xxx, confirm=true |
Creates and confirms the payment. $189 charged to Amex. |
| 20 | MCP Engine → Vault | vault.read("cw-pvt-{alice}-cw-email-access-token") → hit! (Google OAuth) |
Email connector is locked: "user" — only checks private vault, no cascade |
| 21 | MCP Engine → Google OAuth | POST https://oauth2.googleapis.com/token (refresh_token → new access_token) |
Access tokens expire hourly. Refresh before use. |
| 22 | MCP Engine → Gmail SMTP | SMTP smtp.gmail.com:587 + XOAUTH2 authTo: alice@acme.com • Subject: "Flight Booked: BOS→JFK" |
Sends confirmation email from Alice’s own Gmail account |
| 23 | MCP Engine → Google Calendar API | POST https://www.googleapis.com/calendar/v3/calendars/primary/events{"summary":"Flight BOS→JFK","start":"2026-05-01T08:00:00"} |
Creates calendar event on Alice’s Google Calendar |
| 24 | Agent → Azure OpenAI | LLM sees all 4 tool results, generates natural language summary | Final LLM call to compose the response |
| 25 | Agent → Browser (SSE) | Streams response token-by-token to the chat UI | User sees the answer appear in real-time |
| Capability | Traditional Apps | Other AI Platforms | ContextWeaver |
|---|---|---|---|
| User says one sentence | ❌ Click through 5 screens | ⚠️ Chat but can’t act | ✅ Searches, books, charges, emails |
| Multi-system orchestration | ❌ Separate apps | ⚠️ Hardcoded integrations | ✅ LLM chains tools from any plugin |
| Per-user credentials | ✅ Each user logs in | ❌ Shared API keys | ✅ Vault cascade: user → group → org |
| Policy enforcement | ✅ Code-enforced rules | ❌ No policy awareness | ✅ RAG-based: org + group + user tiers |
| Same request, different users | ✅ Role-based access | ❌ Same result for everyone | ✅ Different policies, credentials, outcomes |
| Add new capability | ❌ Months of development | ⚠️ API integration work | ✅ No-code: drag connector + attach to plugin |
| Card data security | ✅ PCI compliance | ❌ Often stores tokens | ✅ Stripe Checkout — card data never touches CW |
| Policy updates | ❌ Code changes + deploy | ❌ Prompt engineering | ✅ Ingest from any data source — instant policy enforcement via vectorized RAG |
These are the most common concerns people have. Here's how ContextWeaver addresses each one.
Short answer: The AI never sees your passwords, card numbers, or API keys.
Think of it this way: the AI is like a personal assistant who knows your name but not your PIN. It tells the bank what to do, but the bank handles the actual money. The assistant never touches cash.
Short answer: We use Stripe, which is PCI DSS Level 1 certified — the highest security standard in the payments industry.
cus_abc123 (a Stripe customer ID) — not a card number. Even if someone accessed our vault, they'd get an ID that means nothing outside Stripe.If a hacker breached ContextWeaver, what would they get? Encrypted vault entries containing Stripe customer IDs (useless without Stripe's API key) and policy documents (your travel rules — not financial data). No card numbers. No bank accounts. No passwords.
Short answer: The vault uses industry-standard secret managers — the same ones that protect bank infrastructure.
| Vault Backend | Where Data Lives | Encryption | Who Uses It |
|---|---|---|---|
| Azure Key Vault | Microsoft Azure data center (your region) | AES-256 + HSM hardware | Banks, governments, Fortune 500 |
| HashiCorp Vault | Your own servers or cloud | AES-256-GCM, Shamir sealing | Stripe itself, NASA, Adobe |
| AWS Secrets Manager | Amazon AWS data center | AWS KMS encryption | Netflix, Airbnb, Capital One |
| Local File (dev only) | Your machine (development/demo) | Not for production | Local testing only |
In production, your vault is never on the same server as the AI. The AI requests a secret, uses it for one API call, then discards it. The secret is never written to disk, never included in logs, and never sent to the LLM.
Short answer: We only use third parties that are independently audited and certified.
Key principle: ContextWeaver is a conductor, not a warehouse. It orchestrates actions between systems you already trust (Stripe, Gmail, Azure) but never stores your actual financial or personal data itself. Your data stays where it already is — in the systems designed to protect it.
Short answer: Each action uses its own isolated credential lookup. Nothing is shared between steps.
Even though you gave one instruction, each tool call is a separate, isolated execution. The Stripe key used in Step 3 is resolved fresh from the vault, used for that one API call, and immediately discarded. It's never passed to the email step, never stored in memory, and never sent back to the AI. Think of each step as a separate locked room — they can't see into each other.
Your financial data never enters ContextWeaver. It stays in Stripe, Gmail, and your vault — systems designed and audited to protect it.
The travel example above used 3 connectors (Travel + Payments + Email). But ContextWeaver isn't a travel app — it's a platform for building any service by combining connectors like Lego blocks:
🧱 Build. Proxy. Extend. Combine. — Unlimited Possibilities.
Every popular application can become a connector. Every connector can be combined with others.
The result: any service imaginable — travel, DevOps, healthcare, finance, HR, logistics — built from the same secure, policy-aware platform.
One sentence. Three connectors. Policy-aware. Per-user credentials.
The AI searched flights, checked your budget, charged your card, and emailed your confirmation.
No screens. No forms. No code changes.
And this is just one combination. With enough connectors — built, proxied, or extended —
ContextWeaver becomes a Lego system for building any AI-powered service,
for B2B enterprise or B2C consumer, with enterprise-grade security built in.