Tools, Resources, and Prompts

Expanded Definition

In MCP-style interfaces, tools, resources, and prompts are the three primitives that define how an AI agent can act, what information it can read, and how its behavior is shaped. Tools are callable actions with side effects or executable capability, resources are retrievable data sources, and prompts are reusable instruction templates. In NHI and Agentic AI governance, the distinction matters because each primitive creates a different control surface: tools expand execution authority, resources expand data exposure, and prompts influence task framing and output behavior. Definitions vary across vendors, but the security question is consistent: what is the agent permitted to invoke, inspect, or inherit from context? For background on broader identity and access governance expectations, the NIST Cybersecurity Framework 2.0 is useful for mapping authorization and monitoring responsibilities. The most common misapplication is treating all three as equivalent configuration objects, which occurs when teams grant prompt access and tool access under the same review process.

Examples and Use Cases

Implementing tools, resources, and prompts rigorously often introduces governance overhead, requiring organisations to weigh agent flexibility against tighter authorization and logging controls.

• A support agent uses a ticketing tool to create cases, while a resource exposes customer status records and a prompt standardizes escalation language.
• An internal developer assistant reads repository metadata as a resource, but can only trigger a deployment tool after approval and scoped authentication.
• A finance agent retrieves invoice data through a resource, then uses a prompt template to generate variance explanations without direct payment execution.
• A security assistant accesses alert feeds as resources and invokes a containment tool only when policy allows the action to proceed.

These patterns map closely to the kinds of control decisions discussed in NHI governance research such as ASP.NET machine keys RCE attack and Gladinet Hard-Coded Keys RCE Exploitation, where exposed execution paths and embedded secrets became operational risks. The same design logic applies when prompts shape behavior but do not themselves grant authority, while tools and resources do.

Why It Matters in NHI Security

These primitives matter because they define the practical boundary of agent authority. If tools are too broad, a compromised agent can make privileged changes. If resources are overexposed, the agent may retrieve secrets, tokens, or sensitive records it never needed. If prompts are unmanaged, an attacker can steer an agent into unsafe execution patterns or policy bypass. NHI Management Group data shows that 97% of NHIs carry excessive privileges, which is why tool access must be treated as a least-privilege problem, not just an integration detail. The same discipline also supports visibility, since only 5.7% of organisations have full visibility into their service accounts, making agent permissions and context usage difficult to audit. For identity and lifecycle governance, the Ultimate Guide to Non-Human Identities is a core reference point. Organisational risk becomes especially visible in zero trust programs, where agent actions must be explicit and traceable rather than assumed. Organisations typically encounter the consequence only after an agent reads too much, invokes the wrong tool, or is abused through prompt injection, at which point the tools, resources, and prompts model becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams govern prompts submitted to browser-based AI tools?
• What do teams get wrong about tools versus resources in MCP?
• How should security teams prevent jailbreak prompts from reaching agent tools?
• How should security teams govern private AI chat tools that retain prompts differently?