Skip to content
AdminKit

AI agents & MCP

The Model Context Protocol lets AI agents call tools and read resources over a network connection, which means an unauthenticated or misconfigured MCP server can hand an agent — or an attacker — more access than intended.

Tools (1)

All tools →

Guides (6)

All guides →

Glossary (24)

Full glossary →
  • Completion (MCP) — Completion, in the Model Context Protocol, is a request type -- completion/complete -- that lets a server offer argument autocompletion for a prompt or a resource template's URI, the same kind of suggestion list an IDE shows while typing. A client sends the argument's name and the characters typed so far, naming which prompt or template it's completing against, and for a request with more than one argument it can include previously-resolved values as context so later suggestions depend on earlier ones. A server that supports this declares the completions capability during initialization; its response returns a ranked array of suggested values, capped at 100 per response, with an optional total count and a flag for whether more matches exist beyond that cap. The specification recommends servers rate-limit these requests, since an endpoint that echoes back whatever matches a partial query can itself leak sensitive values.
  • Confused deputy problem — The confused deputy problem is a classic security flaw where a program with legitimate authority to perform an action is tricked by a less-privileged caller into misusing that authority on the caller's behalf -- the "deputy" (the privileged program) is confused about whose request it's actually acting on. In MCP and other agent-tool systems, this shows up when a gateway or server simply passes through a token it received, rather than checking that the token was actually intended for it (the token's "audience"); a malicious client can then route a token meant for one service through to another, tricking the receiving service into granting access it never should have. The fix is validating token audience and scope at every hop, not forwarding credentials blindly between services.
  • Context window — A model's context window is the maximum number of tokens -- the prompt, any system instructions, tool definitions, retrieved content and the model's own output -- it can process in a single request, a limit set per model by its own vendor rather than by any shared industry specification. Everything an AI agent feeds into a request has to fit inside this budget together, which means a tool response, a retrieved document or an MCP resource competes for the same space as the user's own instructions. This matters for security as well as capacity: text embedded in a long tool response or fetched document sits in the same context window as trusted instructions, with nothing in the window itself distinguishing the two, which is exactly the gap prompt-injection defenses have to close outside the model.
  • Elicitation (MCP) — Elicitation is a Model Context Protocol capability that lets a server pause mid-task and ask the client to collect additional information from the user, instead of having to request everything a tool might need up front, or guessing at missing input. The specification requires clients to present an elicitation request to the user for explicit review rather than auto-filling or auto-approving it, and servers are barred from using elicitation to request sensitive information such as passwords or other credentials through this channel. Because an elicitation prompt is server-authored text shown to the user mid-session, it's also a path a malicious or compromised server could misuse to phish for information under a trusted-looking prompt, which is why the same explicit-confirmation discipline recommended for tool calls applies here too.
  • JSON-RPC — JSON-RPC is a lightweight remote procedure call protocol that encodes a method name, parameters, and an identifier as a JSON object, letting one system ask another to run a named operation and return a result or error in a matching JSON reply. Version 2.0, the version in current use, is the wire format the Model Context Protocol (MCP) builds on: an MCP client sends JSON-RPC requests like initialize or tools/list to a server, which responds with a JSON-RPC result carrying its capabilities or exposed tools. Because JSON-RPC itself defines only the message shape, not authentication or transport security, an MCP server's actual protection against unauthorized calls depends entirely on what the server (or a gateway in front of it) adds on top.
  • MCP (Model Context Protocol) — MCP (Model Context Protocol) is an open standard that defines how AI agents and assistants connect to external tools, data sources, and services through a common interface, instead of every integration needing its own custom, one-off connector. An MCP server exposes a set of tools or resources an agent can call; an MCP client, often an AI application, discovers and invokes them following the protocol's shared conventions for authentication, request/response shape, and capability discovery. Because MCP servers are increasingly exposed to untrusted or semi-trusted agents, the protocol's own specification includes security considerations -- like avoiding naive token passthrough -- that implementers have to actively follow rather than assume are automatic.
  • OAuth for MCP — The Model Context Protocol's authorization specification defines how an MCP client obtains and presents credentials to an MCP server using OAuth 2.1, rather than leaving every implementer to invent its own authentication scheme. An MCP server acting as an OAuth resource server can require a client to complete an authorization flow before it will serve a request, and the specification's security guidance specifically warns against naive "token passthrough" -- forwarding a token issued for one service straight through to another -- since a token isn't guaranteed to be valid for the second service's intended audience, a failure mode related to the confused deputy problem. Because MCP servers are increasingly exposed to agents acting with real tool access, following this specification rather than skipping authorization, or implementing it incorrectly, is what actually determines whether a server's tools are protected from unauthorized callers.
  • Progress notification (MCP) — A progress notification is how the Model Context Protocol reports incremental status on a request that may take a while to finish, such as a long-running tool call. A client that wants updates attaches a progressToken to its original request's metadata; whichever side is handling that request then sends one or more notifications/progress messages carrying the same token along with a progress value and, optionally, a total, so the other side can show a percentage or step count instead of leaving the user staring at a frozen screen. Like all MCP notifications, these are plain JSON-RPC notifications -- they carry no id and expect no reply -- and sending them at all is optional for an implementation to support, so a client cannot assume it will receive one without checking first.
  • Prompt (MCP) — A prompt in the Model Context Protocol is a predefined, parameterized template a server exposes for a client to surface to its user -- for example as a slash command or menu item -- to kick off a specific interaction, distinct from a tool, which a model invokes on its own, and a resource, which supplies reference data. A client lists a server's available prompts, then retrieves a chosen one by name along with whatever arguments it accepts, and the server returns the actual message content to send to the model; a server can also notify a client when its prompt list changes. Because prompts are user-controlled rather than model-controlled, a server with a seemingly reasonable set of exposed prompts still deserves the same review as its tools, since a prompt's underlying template can embed the same kind of unreviewed instructions a malicious tool description would carry.
  • Prompt injection — Prompt injection is an attack where text an AI agent reads as part of its task -- a web page, a document, a tool's response -- contains instructions crafted to manipulate the agent into doing something the user never asked for, because the model doesn't reliably distinguish trusted user instructions from untrusted content the task involves. A direct injection targets the model's own prompt interface; an indirect injection hides the instructions inside content the agent is only supposed to read, the more dangerous variant once agents have tool access, since a page the agent merely visits can trigger an unwanted email or API call. It needs no software bug, since it targets instruction-following behavior directly, which is why defenses focus on treating read content as data rather than commands, scoping which tools an agent can call without confirmation, and validating tool outputs instead of filtering every malicious phrase.
  • Resource (MCP) — A resource in the Model Context Protocol is a piece of data or content -- a file, a database record, an API response -- that an MCP server exposes to a client by URI, for the client to read and feed into a model's context, as distinct from a tool, which performs an action rather than returning data for reference. A client typically lists a server's available resources, then reads a specific one by its URI when it's relevant to the current request, and a server can also notify a subscribed client when a resource's contents change. Because resources often carry the same files, records or internal API responses a tool call would also expose, a server's resource list deserves the same deliberate scoping before deployment as its tool list does, not an assumption that only tools need reviewing.
  • Resource template (MCP) — A resource template is how a Model Context Protocol server exposes a parameterized family of resources -- for example file:///{path} covering every file under a project directory -- as a single URI template, defined using RFC 6570 syntax, rather than listing every concrete resource individually. A client discovers a server's templates through a resources/templates/list request, separate from the plain resources/list call that returns already-concrete URIs, and fills in a template's variables, often with help from the protocol's completion API, to read a specific resource it names. Because one declared template can stand in for an entire directory tree or an entire database table's worth of concrete resources, it deserves the same deliberate access-control review as a server's static resource list -- a template that looks narrow in its definition can still expose far more than a reviewer scanning a resource list by name alone would assume.
  • Roots (MCP) — Roots are a Model Context Protocol mechanism for a client to tell a server which filesystem directories it's permitted to operate within, exposed through a client capability the server can query at the start of a session. A client exposing roots -- for example, a desktop AI application with a project folder open -- advertises one or more URIs as its roots, and a well-behaved server is expected to confine any file operations its tools perform to those boundaries rather than reaching elsewhere on disk. Roots are advisory in the specification, not an enforced sandbox: a server still has to honor them voluntarily, so they reduce the chance of a tool call touching an unrelated directory by mistake rather than guaranteeing it can't happen against a server that ignores the signal.
  • Sampling (MCP) — Sampling is a Model Context Protocol primitive that lets an MCP server ask the client to run a completion against the client's own LLM, rather than the server needing its own model access -- useful when a server's tool needs an AI-generated judgment call partway through a task. The MCP specification requires that sampling requests go through the human in the loop: a client implementing sampling must let the user review and approve both the prompt being sent and the completion coming back before it's used, rather than silently fulfilling the server's request. This mirrors the consent requirement the specification places on ordinary tool calls, and for the same reason -- a server a client didn't fully vet could otherwise use sampling to generate and act on content the user never saw.
  • Server-sent events (SSE) — Server-sent events (SSE) is a web standard, part of the WHATWG HTML specification, that lets a server push a one-way stream of text events to a client over a single long-lived HTTP connection, without the client needing to poll repeatedly. The Model Context Protocol used an HTTP-plus-SSE transport in its original 2024-11-05 specification for networked servers, pairing regular HTTP requests with an SSE stream for server-to-client messages, before replacing it with the Streamable HTTP transport in the 2025-03-26 specification, which folds both directions into ordinary HTTP request and response bodies instead. A server or client built against the older transport isn't automatically compatible with a Streamable-HTTP-only implementation, which matters when connecting an agent to an MCP server that hasn't been updated to the current specification.
  • SSRF — SSRF (Server-Side Request Forgery) is a vulnerability where an attacker tricks a server, or an AI agent calling tools on its behalf, into requesting a destination the attacker chooses rather than the one intended. A classic example is a "fetch this image URL" feature pointed at an internal address like a cloud metadata endpoint, getting the server to reach places that aren't reachable from the public internet at all. The risk has grown with AI agents and MCP tool integrations, because an agent that can fetch arbitrary URLs on a user's behalf is itself a server-side requester, steerable by untrusted input the agent reads mid-task. Mitigations include allow-listing destinations, blocking requests to private/link-local and metadata addresses by default, and validating any URL from untrusted input before the request is made, not after.
  • stdio transport (MCP) — The stdio transport is one of the ways a Model Context Protocol client and server exchange JSON-RPC messages, using the server process's standard input and standard output streams instead of a network socket. The client spawns the MCP server as a local child process, writes requests to its stdin, and reads responses from its stdout, which works well for a server running on the same machine as the client -- a desktop AI application or IDE integration launching a local tool server, for example -- but can't be used for a server on a different machine, since no network transport is involved at all. MCP's other current transport, Streamable HTTP, replaced an older SSE-based transport and is used instead whenever the client and server aren't on the same host. AdminKit's own adminkit-mcp connector defaults to stdio, with an --http flag available when a remote client needs network access instead.
  • Streamable HTTP transport (MCP) — Streamable HTTP is one of the two transports the Model Context Protocol specification defines for how a client and server exchange its JSON-RPC messages, the other being stdio. Where stdio requires the client to spawn the server as a local child process and talk over its standard input and output, Streamable HTTP lets the server run as a standalone, long-lived HTTP service that a client connects to over the network -- the transport a remote or hosted MCP server needs, since stdio has no concept of a different machine at all. It replaced an earlier HTTP-plus-SSE transport in the MCP specification. AdminKit's own adminkit-mcp connector defaults to stdio but supports an --http flag (adminkit-mcp --http :8080) to serve Streamable HTTP instead, for exactly the case where a remote agent, rather than a locally spawned one, needs to connect.
  • Structured content (MCP) — Structured content is an optional field, structuredContent, a Model Context Protocol tool can return in its call result alongside -- not instead of -- the usual content array of text, image or resource blocks, carrying the result as a plain JSON object rather than text a client has to parse back out itself. A tool definition can declare an outputSchema, a JSON Schema describing the shape that result is expected to take; when it does, the server MUST return structured content conforming to it, and a client SHOULD validate the response against that schema before trusting it. For backwards compatibility, a tool returning structured content should still serialize the same JSON into a text block too, so an older client that only understands unstructured content doesn't break. The specification notes this is unrelated to LLM "structured outputs" (schema-constrained model generation).
  • System prompt — A system prompt is the instruction set an application gives an AI model before a conversation or task starts, establishing its role, behavior boundaries and what it's permitted to do, as distinct from the user's own input and from any content the model reads afterward while performing a task. Because a model reads its system prompt and the content it later encounters -- a web page, a document, a tool's response -- through the same text channel, it doesn't automatically know which parts are trusted instructions and which are untrusted data, which is the root cause of prompt injection. AdminKit's guide to securing an MCP server flags this directly: text that merely resembles system-prompt-style instructions, embedded in otherwise ordinary tool output, is a common red flag worth filtering before it reaches the model, precisely because the model can't reliably tell a genuine system prompt from an imitation.
  • Tool allowlist — A tool allowlist is a security control that restricts an AI agent, or the gateway mediating its access, to a named, pre-approved set of tools it may call, rejecting any tool call outside that set even if the underlying server exposes more. This matters because an MCP or similar agent-tool server can expose far more capability than a given task needs, change its exposed tools over time, or be manipulated into offering a malicious tool under a trusted-sounding name; an allowlist means that even a compromised or misconfigured server can't silently widen what an agent is able to do. It's a narrower, more auditable alternative to trusting an agent's own judgment or a server's self-reported tool list at call time.
  • Tool annotations (MCP) — Tool annotations are optional metadata a Model Context Protocol server attaches to a tool's definition -- hints such as readOnlyHint, destructiveHint, idempotentHint and openWorldHint that describe what kind of effect calling the tool is expected to have. A client or gateway can use these hints to decide how much friction to apply before a call goes through, for instance requiring explicit confirmation before a tool flagged as destructive runs, while letting a read-only one proceed more freely. The specification is explicit that annotations are untrusted hints, not a security boundary: a server can declare any value it wants, including a false readOnlyHint on a tool that actually deletes data, so a client that treats annotations as guaranteed rather than advisory is trusting the same server it may not have otherwise vetted.
  • Tool poisoning — Tool poisoning is an attack against AI agents using the Model Context Protocol (MCP) or similar tool-calling frameworks, where a tool's description or metadata is crafted to manipulate the agent reading it, rather than exploiting the tool's actual function. An agent typically reads a connected server's tool descriptions as trusted context for deciding how and when to call them, so hidden instructions in that description -- invisible to the user, who only sees the tool's name -- can steer the agent into leaking data to the wrong tool, skipping a safety check, or calling a different tool than intended. The attack is especially effective against servers pulled from an unvetted public registry, since descriptions load automatically and can change after a user first approves the server (sometimes called a rug pull). Mitigations include pinning and diffing tool definitions on every connection, treating descriptions as untrusted input, not instructions.
  • Transport security (MCP) — MCP transport security refers to the protections the Model Context Protocol specification requires for exchanging messages, which differ by transport. For stdio, where a client spawns the server as a local subprocess, the specification treats the operating system's process boundary as the trust mechanism and expects credentials from the environment rather than a network auth flow. For Streamable HTTP, the specification's security guidance is explicit: a server MUST validate the Origin header on incoming connections to prevent DNS rebinding attacks, SHOULD bind only to localhost rather than all interfaces when running locally, and SHOULD implement authentication -- without which an attacker's web page could use DNS rebinding to reach a server a user only intended to run locally. Treating every transport as equally exposed, or skipping these checks because a server 'just runs locally,' is a common and avoidable gap.

Comparisons (2)

All comparisons →

Solutions (1)

All solutions →

Related clusters

Machine protocols

MQTT, Modbus, RDP, VNC and the other protocols your devices and legacy systems speak were mostly designed for trusted local networks, not the open internet — exposing one is a common way in for an attacker.

Security basics

TLS certificates, HTTP security headers and open ports are the fundamentals every internet-facing service should get right, independent of which protocol or cloud it runs on.

See all six clusters →

Frequently asked questions

What belongs in the AI agents & MCP cluster?

The Model Context Protocol lets AI agents call tools and read resources over a network connection, which means an unauthenticated or misconfigured MCP server can hand an agent — or an attacker — more access than intended. This hub lists every AdminKit tool, guide, glossary term, comparison and solution tagged with this cluster.

How does AI agents & MCP relate to Machine protocols and Security basics?

Machine protocols — MQTT, Modbus, RDP, VNC and the other protocols your devices and legacy systems speak were mostly designed for trusted local networks, not the open internet — exposing one is a common way in for an attacker. Security basics — TLS certificates, HTTP security headers and open ports are the fundamentals every internet-facing service should get right, independent of which protocol or cloud it runs on.