AI control, explained.

An AI agent is software that pursues a goal by running a loop: it sends the task and its available tools to a model, the model chooses the next action, the agent executes it, with real side effects, and the result feeds the next turn, until the task is done. Unlike a chatbot, an agent acts. And because models are non-deterministic, the same task can take four steps today and twelve tomorrow: variance is the material these systems are made of, not a defect.

A2A is an open protocol, governed by the Linux Foundation, that lets AI agents built on different frameworks discover and work with each other. Each agent publishes an agent card, a machine-readable description of its capabilities, at a well-known URL, and other agents send it tasks over a standard message format. Version 1.0 added cryptographically signed agent cards, giving agents verifiable identity rather than self-declared descriptions.

Agent identity is the practice of giving each AI agent its own first-class identity, instead of a shared API key, so that every action an agent takes can be attributed, authorized, and revoked individually. It matters because agents act autonomously: when something goes wrong, “which key was used” is a much weaker answer than “which agent did what, under whose authority.”

The agent lifecycle is the managed progression of an AI agent through production: from definition and approval, through live operation, to monitoring, intervention, and eventual retirement. Most tooling concentrates on the build phase; the lifecycle that determines risk starts the day the agent ships, because that is when it acts unsupervised, drifts, and eventually needs to be changed or retired.

Agent skills are packaged, versioned units of capability for AI agents, typically a SKILL.md instruction file plus scripts, templates, and resources, that an agent loads progressively when a task calls for them. The convention originated with Anthropic’s Agent Skills specification, and while unqualified “skills” can mean anything from prompt libraries to assistant plug-ins, agent skills names this specific portable format. Most platforms treat skills as artifacts to author, version, and sync to agents; the governance question is what happens when the skill actually runs.

An AI asset registry is the inventory of every AI asset an organization runs, models, tools, agents, and AI systems, each with an owner, a purpose, and a governance state. It is the object regulation actually asks for: the EU AI Act expects an inventory of AI systems, and ISO/IEC 42001 scopes its management system around one. It differs from an MCP registry: that is a catalog of tools teams may use; the asset registry is the record of everything that exists, including what nobody cataloged.

AI compliance is demonstrating that an organization’s AI use meets the requirements of laws and frameworks, the EU AI Act, SOC 2, ISO/IEC 42001, HIPAA, GDPR, with evidence rather than assertions. It has two halves: operating AI within the rules, and being able to prove it when the auditor arrives. The frameworks increasingly expect runtime records: not “we have a policy,” but “here is every decision the policy made.”

An AI control plane is the management layer that governs an organization’s entire AI estate, models, tools, agents, and spend, through one point of policy, identity, and observability. The term borrows from network and Kubernetes architecture: the data plane moves traffic, the control plane decides what is allowed. Where an AI gateway routes and secures calls, a control plane adds the estate-wide layer: inventory, cost, compliance evidence, and control over AI that does not route through it.

AI economics is the strategic view of what AI costs and returns across a business: total cost of ownership, return on investment, and whether building, buying, or running a given AI capability is viable over time. It sits at the top of a ladder of related terms. Below it, tokenomics measures how token consumption becomes cost and value; FinOps for AI organizes who owns the spend and whether it is forecastable; and AI cost control enforces limits and reduces cost in the request path. Most organizations can answer the bottom two questions today and not the top two, which is why AI budgets keep surprising their owners.

An AI gateway is a proxy that sits in the request path between applications and AI providers, applying routing, security, and cost controls to every call. It evolved from the API gateway: where API gateways manage REST traffic, AI gateways understand LLM requests, MCP tool calls, and agent-to-agent messages, and add AI-specific controls like prompt guardrails, token budgets, and model failover. One integration point, many providers, uniform policy.

AI governance is the set of controls and evidence an organization applies to its AI use: who may use which models and tools, within what limits, and with what record. It spans two worlds that are converging: organizational governance (policies, risk assessments, compliance workflows) and runtime governance, where rules are enforced in the request path as AI is actually used. Analysts increasingly treat runtime enforcement as the part that makes the rest real: a policy that nothing enforces is documentation.

An AI System is the unit modern AI regulation governs: not the model, but the composition, the caller plus every model, tool, and data source it may use, plus the rules bound to it, with an owner, a stated purpose, a lifecycle stage, and a risk tier. You do not deploy a model; you deploy an AI System. They come in more kinds than agents alone: agent, assistant, application, workflow, integration, and service.

An API key vault stores AI provider credentials centrally and encrypted, so applications and developers never hold raw OpenAI, Anthropic, or other provider keys. Clients get scoped stand-in credentials instead, resolved server-side on each call. The payoff is blast radius: a leaked scoped key is revoked in one place with its spend limits attached, and rotating a provider key no longer means hunting it down across codebases and CI systems.

An argument policy is a governance rule that parses the arguments of a tool call, the SQL statement, URL, shell command, file path, or JSON payload, and applies syntax-aware rules to them. Text-level checks cannot tell a harmless query from a destructive one; an argument policy understands the language being passed, so it can allow reads and refuse writes in the same tool.

Batch processing submits a large set of model requests as one asynchronous job with a completion window, typically 24 hours, instead of call-by-call: the pattern behind classification backlogs, document pipelines, and evaluation runs, usually at a lower per-token price from providers. The governance catch is that batch traffic is easy to treat as exempt, yet it is often the highest-volume path your data takes to a model.

Behavioral drift is gradual change in an AI system’s behavior without any code deploy on your side: a provider silently updates the model, a tool definition changes, the data shifts. It is invisible to uptime monitoring because every request still succeeds; what changes is the behavior between the requests: more steps, different tools, rising cost, worse outcomes.

Big-T notation classifies AI workloads by how their token cost grows as usage grows: the analytical discipline Big-O brought to software performance, applied to the AI bill. Defined by the Tokenomics Foundation, the classes run T(1) (constant: the cache answers), T(log n) (sublinear: deterministic code shrinks the input first), T(n) (linear: one model call per task, the healthy default), T(n·k) (multiplicative: k calls per task from reasoning steps and tool chains), T(n·k·a) (agent-multiplicative: delegation compounds two multipliers; the Foundation calls it “the O(n²) of AI”), and T(∞) (a loop with no termination condition). Class, not spend, is the early warning: a workload that behaves at ten users can detonate at a thousand if it was T(n·k) all along and everyone assumed T(n). The classes, with the growth curves drawn, are in A Practical Guide to AI Tokenomics.

In AI operations, a contract is the written statement of what a deployed AI system is allowed to be: which models, tools, and data it may use, which policies apply, and the limits one task may not exceed. Its value is that it is versioned and pinned: a run can be tied to the exact contract in force when it happened, a change can be reviewed as a diff, and “did it change” becomes a question with a checkable answer.

Cost per task, more precisely cost per completed task, is the unit-economics metric for AI: spend divided by units of work that actually finished. Providers cannot compute it, by construction: they price API calls, and nothing in a request tells them which calls make up one resolved ticket or one finished report. That knowledge exists only where the work is orchestrated, on your side of the API. The metric turns “what did we spend?” into “what does the work cost?”, the number a budget promise can actually be written against.

FinOps for AI applies cloud financial-operations discipline to AI spend: allocating costs to teams and products, setting budgets, tracking unit economics (cost per token, per call, per agent run), and catching anomalies before the invoice does. It answers “what did we spend, and who owns it”; what a completed task costs, and how that cost grows, is the adjacent discipline of tokenomics. It is now a mainstream FinOps Foundation practice area, complicated by the fact that AI spend spans API calls you route, SaaS subscriptions you buy, and infrastructure you run.

The EU AI Act is the European Union’s regulation of AI systems, applied by risk tier: prohibited practices, high-risk systems with documented obligations, transparency duties, and rules for general-purpose models. Its obligations phase in on dates through 2027, and they attach to the AI system and the role an organization plays for it (provider or deployer), which is why an inventory of AI systems with owners and risk tiers is the practical starting point.

AI guardrails are in-path checks on what goes into and comes out of AI models: detecting and blocking (or redacting) personal data, prompt-injection attempts, secrets like API keys, and toxic content. Input guardrails protect the model from malicious or careless prompts; output guardrails protect users and data from what the model returns. Streaming output guardrails, applied while a response is still being generated, are the harder, rarer variant.

Human-in-the-loop is the pattern of pausing an automated action for human approval before it proceeds. For AI agents it is the safety valve for high-impact operations: the agent can prepare the action, but a person authorizes it. Good implementations make approval auditable and unforgeable: the approval applies to one specific action, once.

ISO/IEC 42001 is the international standard for AI management systems (AIMS), published in 2023: the certifiable framework for how an organization governs its AI: roles, risk, lifecycle, monitoring, improvement. It is voluntary, unlike the EU AI Act, but increasingly what enterprise procurement asks for; certification is becoming the ticket to regulated-industry deals, and it pairs naturally with the Act: the law sets the obligations, the standard shows a way to run them.

In an AI platform, a knowledge base is a curated collection of company content, documents, wikis, tickets, indexed as vectors so models can answer from your facts (see RAG). The hard questions are less about embeddings than about boundaries: who may query which collection, how content stays in sync with the system it came from, and whether the source’s structure and permissions survive ingestion.

An LLM is a neural network trained on massive text corpora to understand and generate language: the model class behind ChatGPT, Claude, and Gemini. In enterprise conversation, “LLM” has stretched into shorthand for AI models in general, including ones that generate images, audio, and video; when precision matters, model is the broader word and LLM is its text-first subset. Operationally they behave alike, token-based pricing, prompt-driven behavior, provider APIs, which is why they can be governed alike.

MCP is the open standard that lets AI applications and agents use external tools and data through one uniform interface. An MCP server exposes capabilities, query a database, search a wiki, file a ticket, and any MCP-aware client can discover and call them. Introduced by Anthropic in 2024 and now governed under the Linux Foundation’s Agentic AI Foundation, it has become the de facto way enterprise agents reach systems of record.

An MCP gateway proxies Model Context Protocol traffic the way an API gateway proxies REST: MCP servers are registered centrally, clients connect through one endpoint, and the gateway applies authentication, per-tool access control, and logging to every call. It solves MCP’s enterprise problem, dozens of servers, hundreds of tools, every client connecting directly, by putting one governed hop in the middle.

An MCP registry is a catalog where MCP servers are published and discovered: the address book of the tool ecosystem. The official MCP registry specification (December 2025) defines how registries federate, so an enterprise can run a private subregistry that mirrors the public ecosystem and adds its own internal servers. A registry answers “what exists”; it takes a gateway to control what is actually called: the registry is the yellow pages, the gateway is the switchboard.

An OAuth proxy stands between AI clients and the SaaS systems their tools reach: it runs the OAuth flow on the user’s behalf and keeps the resulting tokens server-side. Without one, agent frameworks and MCP clients end up holding long-lived Jira, Slack, and GitHub tokens on laptops. With one, the client carries a short-lived stand-in credential; the real token stays vaulted and auto-refreshed, and every call runs under the actual user’s identity.

OpenTelemetry (OTel) is the open, vendor-neutral standard for emitting traces, metrics, and logs, carried over its OTLP protocol to whichever observability backend you run: Grafana, Datadog, Splunk. For AI infrastructure it is the difference between a black box and a component your SREs monitor like any other: gateway latency, token throughput, and error rates land in the dashboards they already watch.

Policy-as-code is managing governance rules as versioned, reviewable artifacts, files in source control, instead of settings clicked in a console. Rules become diffable (what changed), attributable (who changed it), promotable (dev to prod), and revertible. For AI governance it is the difference between “we configured it at some point” and a review trail.

RAG grounds a model’s answer in retrieved content: the question is embedded, the most relevant chunks are fetched from a vector index of your documents, and the model answers from those chunks instead of from training memory alone. It is the standard remedy for stale knowledge and invented facts, and the reason “which documents can the model see?” became a governance question: retrieval reach is data access.

A resource group is a governance boundary: a named scope that holds the resources a set of callers may use and the rules that apply when they use them. Arranged hierarchically, organization, department, team, system, it lets a platform resolve “what may this request do, and at what cost” by walking one tree instead of consulting a dozen per-resource settings. Its usefulness depends on inheritance being predictable: a child must not be able to grant itself what the parent denied.

A run is the unit of agentic work: one task, executed as however many model and tool calls the agent needed, four hops or forty. It is the unit you actually care about, because per-request logs record every call and explain none of them; the meaning, what was the task, did it finish, what did it cost, only exists at the level of the run.

Rust is a systems programming language that pairs C-class performance with compile-time memory safety and no garbage collector. For software that sits in the request path, that combination is the point: no garbage-collection pauses means predictable tail latency under load, and the memory-safety bug class behind many proxy and parser CVEs is ruled out at compile time instead of patched afterward.

Semantic caching answers a repeated question from cache even when it is phrased differently: requests are embedded as vectors, and a new request that lands close enough to a stored one returns the saved response instead of a fresh model call. On high-repetition traffic it cuts both cost and latency. The caveat is scope: a cache shared across access boundaries can leak one team’s answers to another, so cache reach has to follow permissions.

A semantic policy is a governance rule written in natural language and evaluated by an AI judge model on each request, catching intent that pattern-based rules miss. “Never commit to pricing” or “don’t extract customer personal data to files” cannot be expressed as a regex; a judge model can recognize both, however they are phrased. Mature implementations run new policies in shadow mode, logging what would have been blocked, before switching them to enforce.

Shadow AI is AI use an organization has not sanctioned and often cannot see: personal chatbot accounts handling company data, API keys nobody registered, agents and MCP servers running on laptops. It is the successor to shadow IT, moving faster, because trying AI requires nothing but a browser. The governance response has three steps: discover what exists, inventory it, and bring what can be routed under policy.

A token is the unit an LLM reads, generates, and bills by: a fragment of a word, roughly four characters of English. Prompts and responses are measured in tokens, and a model’s context window, how much it can consider at once, is a token count too. The word collides with an unrelated security meaning: access tokens such as API keys and JWTs. “Token limits” can be a budget question or a credential question, depending on which kind is meant.

Tokenomics is the discipline of measuring and managing the economics of AI work: what a completed unit of work costs, how that cost grows as usage grows, and whether the value produced justifies it. The vocabulary was standardized by the Tokenomics Foundation, a Linux Foundation body launched in August 2026 in close partnership with the FinOps Foundation, and its defining move is treating cost as a shape rather than an amount (see Big-T notation). Full explainer: A Practical Guide to AI Tokenomics.

The terms around it are young and overlap, so it helps to place tokenomics on a ladder from strategic to operational. AI economics asks whether the AI is worth it at all. Tokenomics measures how token consumption becomes cost and value: cost per task, growth class, cost to serve. FinOps for AI is the organizational practice: who owns the spend, and is it forecastable. AI cost control is the operational layer in the request path: does this call happen, and at what price. The rungs blur, the Foundation uses “tokenomics” for the top two together, but each asks a question the others do not.

A User Portal is the front door to your organization’s own AI: one workspace where employees chat with approved models, call approved tools, and search company knowledge. That is a different thing from an assistant you buy, like Microsoft Copilot or ChatGPT: a sealed product with the vendor’s models and the vendor’s interface, which you can observe and cost but never route (see FinOps for AI). A User Portal is the reverse: you choose the models behind it, your policies screen every call, and every conversation lands in your own audit trail.