Glossary

Minted from your real key, scoped to a budget in dollars and revocable instantly. The agent never sees your primary credential, and when the budget is exhausted the key stops working rather than the charges continuing.

Why it matters: An autonomous loop with your unrestricted production key is an unbounded liability -- one bad plan can spend your whole month. A cap converts an open-ended risk into a known maximum loss.

For example: Mint via POST /agents, revoke via POST /agents/{key}/revoke.

A plain LLM call is one-shot: prompt in, text out. An agent adds a loop -- the model picks a tool, you execute it, feed the result back, and repeat until it's done or you stop it. The 'agentic' part is that control flow is decided by the model at runtime rather than by you at authoring time.

Why it matters: That's the whole appeal and the whole danger. Model-chosen control flow means you cannot enumerate the paths in advance, so correctness has to be enforced at the boundary (what tools exist, what they'll accept, what gets logged) rather than by testing every branch.

For example: 'Read the failing test, find the bug, patch it, re-run' is four tool calls the model sequences itself. You never wrote that sequence down.

Detecting drift, anomalies and degradation, and responding -- sometimes automatically (restart, reroute, roll back), sometimes by paging a human.

Why it matters: AI systems degrade quietly. Nothing throws an exception when answer quality drops 20%; you only find out from customers unless you're measuring.

Sent as a header (`X-API-Key` here), never in a URL -- query strings end up in server logs, browser history and referrer headers. Rotate on a schedule and on any suspicion of exposure; this platform exposes /subscribe/rotate-key for that.

Why it matters: A key in a URL, a git commit, or a client-side bundle is already public. Assume any key that has ever touched a frontend is compromised.

Common shapes: flat subscription (predictable, decoupled from cost), per-call or per-token metering (tracks cost, unpredictable for the buyer), and outcome-based (charge per successful result). Most real products combine a subscription floor with metering above it -- which is what this platform does.

Why it matters: Agents make per-call metering awkward, because one user action can fan out into dozens of model calls the user never asked for. If you meter naively, a retry storm becomes a customer-facing bill you'll end up refunding.

AI trust infrastructure for autonomous systems, organised as eleven trust domains (Identity, Policy, Authorization, Risk, Governance, Verification, ActionProof, Security, Execution Enforcement, Evidence, Observability). It ships in two deployment models: CAIN Studio, hosted by us, and MCPGate, self-hosted by you. Everything else on either site is either one of those domains or a workload that runs on top of them.

Why it matters: Because 'which AI tools do you sell' is the wrong question once agents can act. The useful question is who decided an action was allowed, what enforced that decision, and where the record is -- which is what the fabric is for.

For example: The architecture page at https://cainstudio.online/fabric renders every domain, the services in it, and the coverage gaps, from one module shared by both sites.

Given a proposed action, the control plane resolves the caller's identity, evaluates policy, scores risk, asks the verification layer whether the plan can violate the tenant's constraints, and emits one verdict plus a decision record. On CAIN Studio it is reachable at /fabric/* and its decisions are retrievable by id at /fabric/decisions/{id}.

Why it matters: Separating deciding from enforcing is what lets the same decision be enforced at a hosted gateway or at a boundary inside your own network, unchanged.

CAIN Studio is the hosted/managed deployment -- we run the control plane and the enforcement boundary, you authenticate with one API key on a subscription. MCPGate is the self-hosted/customer-controlled deployment -- same architecture, perpetual license, running in your own network so neither traffic nor evidence leaves it. A subscription or license on either unlocks the other.

Why it matters: It is an operational choice, not a product choice. Teams whose regulator won't accept a hosted control plane can still run the same fabric.

Data drift (inputs change), model drift (a provider updates a model), and tool drift (an MCP tool definition changes). All three degrade behaviour without erroring.

Why it matters: Drift is the main reason a system that passed its tests in March misbehaves in June with no deploy in between. Only monitoring catches it.

An embedding model maps text to a fixed-length vector (this platform uses nomic-embed-text, 768 dimensions). Texts with similar meaning land near each other, so 'find related text' becomes 'find nearby vectors' -- usually cosine similarity.

Why it matters: Embeddings catch paraphrase that keyword search misses ('stop my bot leaking passwords' vs 'DLP'). They also miss exact identifiers that keyword search nails (a product slug, an error code). Good retrieval uses both -- that's hybrid search.

A decision only matters if something binding sits between the agent and the upstream service. Hosted, that is the CAIN Studio platform gateway; self-hosted, it is MCPGate (ToolWarden's sandboxed, injection-screened tool execution). Advice that isn't in the call path is not enforcement.

Why it matters: Most 'AI governance' products score, dashboard, or report. If nothing sits in the path, nothing is prevented -- only described afterwards.

A single authority that maps an identity to current entitlements, so every service asks one place instead of each keeping its own copy of who paid. Here it also spans two sites: a subscription on cainstudio.online grants entitlements on mcpgate.online and vice versa.

Why it matters: Per-service entitlement copies are how cancelled customers keep access for months. One authority means revocation is immediate everywhere, which is only true if the check is live rather than cached at signup.

Interactive like a notebook, but runs are captured -- inputs, config, outputs, metrics -- so a comparison you made last week can be reproduced and trusted.

Why it matters: Prompt work is empirical and easy to fool yourself about. Without recorded runs you're comparing a new prompt against your memory of the old one.

The alternative, fail-open, allows traffic when a check errors or times out. Fail-closed trades availability for the guarantee that unchecked traffic never reaches the model.

Why it matters: Fail-open guardrails create a specific, exploitable failure: put the checker under load and the guardrail evaporates exactly when you'd most want it. It also makes your audit log silently incomplete.

Policy defined outside the application code, enforced at runtime, and recorded in a tamper-evident log. The recording matters as much as the enforcement -- 'we blocked it' is only useful if you can prove it later.

Why it matters: Under regimes like the EU AI Act the burden is on you to demonstrate compliance. A policy that lives in a code comment, or a log you could have edited, demonstrates nothing.

Not a bug to be patched -- a consequence of models being trained to produce plausible continuations. Retrieval reduces it; it does not remove it.

Why it matters: You cannot fix it inside the model, so you handle it outside: ground answers in retrieved sources, check claims against those sources, and make 'I don't know' a legitimate output. Confidence is not calibrated to correctness.

Training adjusts a model's weights; inference uses frozen weights to produce output. Inference cost is what you pay per request, and it's dominated by how many tokens go in and come out.

Why it matters: Nearly every cost and latency problem in an AI product is an inference-shape problem -- prompt too long, output unbounded, retries unmetered. Fix the shape before reaching for a smaller model.

A catalog organised as 'verify & prove correctness', 'secure agents & prevent leaks', 'monetize & go to market' rather than by internal category. You arrive with a problem, not with a product name.

Why it matters: Technology-shaped catalogs only work for people who already know what the thing is called. Job-shaped catalogs work for newcomers, which is most buyers.

An open protocol for advertising tools with typed schemas and calling them, so one server works across MCP-speaking clients instead of needing per-client integration.

Why it matters: It standardises the interface but not the trust: a tool's description is attacker-controllable text that goes straight into the model's context, and definitions can change under you between calls. Pin and verify them.

Logs, metrics and traces, joined well enough to reconstruct one request end-to-end. For agents you additionally need the decision trail: which tool was chosen, with what arguments, and what came back.

Why it matters: Agents fail non-reproducibly. Without the decision trail you cannot distinguish 'the model chose badly' from 'the tool returned garbage' from 'the retrieval was empty', and those have completely different fixes.

Unified Identity gives all three one namespace: urn:cain:principal:<kind>:<id>. Principals are materialised from the identity facts the platform already has (a customer key, an agent sub-key, an account) or registered explicitly with an Ed25519 public key. Raw API keys are never stored -- only a fingerprint of them.

Why it matters: 'Who did this' is unanswerable if agents, people and backend services live in three separate identity systems that never agree.

For example: GET /fabric/identity/whoami with your API key returns the principal that key resolves to, its kind, and its tenant.

On mcpgate.online the bundle is 12 tools under one perpetual license. The other standalone tools are priced independently because two are free and two are separate subscriptions.

Why it matters: Bundling suits tools that are individually narrow but jointly a workflow -- you rarely want an audit log without also wanting the thing being audited.

Any untrusted content the model reads -- a web page, a document, a tool description, another agent's output -- can contain instructions. The model has no reliable way to distinguish your instructions from content, because both arrive as tokens.

Why it matters: This has no known complete fix, so architecture carries the load: least-privilege tools, no ambient credentials, confirmation for irreversible actions. Filters help against known phrasings and are not a boundary.

Instead of hoping a model memorised your documents, you keep them in a store, retrieve the handful of passages relevant to the question, and paste those into the prompt. The model's job shrinks from 'recall' to 'read and summarise', which is the thing it's actually reliable at.

Why it matters: It's the cheapest way to make a model current and citable. It does NOT make it truthful -- if retrieval returns nothing relevant, most models will still answer, just wrongly. That failure mode is why source-hygiene gates exist.

For example: This site's own chatbot is a RAG system: it retrieves from this glossary, the product catalog and the FAQ before answering, and it will tell you it doesn't know rather than invent a product.

Limits on what can be reached and consumed: no ambient network or filesystem access, capped CPU/memory/time, capped output size. For agents the important boundary is the tool-execution layer, since that's where model-chosen input becomes real side effects.

Why it matters: The model is not the attack surface -- the tools are. A model tricked into calling a shell tool is only as dangerous as that shell tool was willing to be.

The default for Fabric enforcement, and for the OPA policy hook and the injection screen before it. Decisions accumulate as real evidence so that turning enforcement on is a decision based on what the checks actually did on your traffic, rather than a guess. /fabric/status reports which mode a deployment is in right now.

Why it matters: Turning a brand-new gate straight to fail-closed on live traffic is how a governance layer causes the outage it was bought to prevent.

The customer checks out on a Stripe-hosted page; Stripe stores the card and charges monthly, then notifies your backend via webhooks (checkout completed, payment failed, subscription cancelled). Your entitlements should be driven by those webhooks, not by what the browser reported after checkout.

Why it matters: Trusting the redirect instead of the webhook is the classic billing bypass -- a user can hit your success URL directly. Also: verify the webhook signature, or anyone who knows the URL can grant themselves a subscription.

Used when real labelled data is scarce or sensitive. A larger model produces examples, you filter them, and fine-tune a smaller model to do that one task cheaply.

Why it matters: The filtering step is the whole game. Unfiltered synthetic data teaches the student the teacher's mistakes with extra confidence, and evaluating on synthetic data from the same generator will hide exactly that.