Open LLM Security Posture Mapping for NIST CSF 2.0

Security objective. Maintain an inventory of LLM applications, model endpoints, agent runtimes, RAG systems, MCP servers, and the external model services they depend on.

An organization cannot assess LLM exposure without identifying the systems, endpoints, data stores, and external services involved. An AI asset inventory records each LLM application and its supporting components, the environment it runs in, its owner, and the authentication boundary that governs access to it.

Risk condition. AI systems are deployed by product and engineering teams without a corresponding security inventory, so the model endpoints, agents, and integrations in production are not fully known to the teams responsible for assessing them.

Expected outcome. The set of LLM applications and their supporting components is identified, attributed to an owner, and kept current as systems are added, changed, and retired.

Assessment evidence

• AI application inventory
• Model endpoint inventory
• Agent and MCP server inventory
• Ownership and environment records
• System lifecycle records

Implementation considerations. Different discovery methods reveal different parts of the surface. Cloud service inventory, source dependencies, API gateway configuration, and DNS each expose a subset. Treat the inventory as a reconciliation of several sources rather than the output of one.

Security objective. Identify the model API endpoints reachable from applications, agents, and internal networks, including test, development, and administrative endpoints.

A model endpoint is the network interface through which an application submits prompts and receives responses. Endpoints exist for hosted provider APIs, self-hosted models, and model gateways. Discovery establishes which endpoints exist, where they are reachable from, and how they authenticate.

Risk condition. Model endpoints are exposed on internal or public networks without a record of their existence, or non-production endpoints remain reachable after their intended use has ended.

Expected outcome. Reachable model endpoints are enumerated and associated with an application, an environment, and an access boundary.

Assessment evidence

• Model endpoint inventory
• Network reachability records
• Endpoint authentication configuration
• Gateway routing configuration

Implementation considerations. Endpoint discovery based only on documented architecture will miss endpoints introduced during development. Combine configuration review with observed network flows where available.

Security objective. Identify external model providers and hosted AI services that process organizational prompts and data.

Applications commonly send prompts to external model providers. Each provider is a supplier that processes organizational data. Identification records which providers are in use, which applications use them, and what data classification reaches them.

Risk condition. External model providers are integrated at the application layer without being recorded as suppliers, so the data that leaves the organization and the terms that govern it are not tracked.

Expected outcome. External model providers and hosted AI services are identified, attributed to the applications that use them, and treated as suppliers within existing supplier management.

Assessment evidence

• External model provider inventory
• Application-to-provider mapping
• Data classification reaching each provider
• Provider agreement references

Implementation considerations. A single application may call several providers, and a provider relationship may be introduced through a dependency or an SDK rather than a direct integration. Reconcile the provider list against outbound network destinations.

Security objective. Identify LLM and generative AI usage that is not recorded in the approved inventory.

Shadow AI is the use of model APIs, embedded SDKs, browser-based AI services, SaaS AI features, application plugins, or developer tooling that is not recorded in the approved inventory. It is defined by the absence of a governance and security record rather than by the identity of the service.

Risk condition. Model integrations reach production through SaaS features, embedded SDKs, plugins, or undocumented endpoints referenced in code and configuration, and these integrations are not represented in the inventory used for assessment.

Expected outcome. Previously unrecorded AI usage is identified, evaluated, and either brought under management or removed.

Assessment evidence

• Source and configuration references to model endpoints
• SaaS AI feature inventory
• Dependency and SDK inventory
• Outbound connections to model provider domains
• Browser and endpoint telemetry where available

Implementation considerations. Scoping matters. Treating all consumer use of a public assistant as shadow AI produces noise. Focus on integrations that process organizational data or connect to organizational systems.

Security objective. Maintain an inventory of the software dependencies that compose LLM systems, including SDKs, agent frameworks, MCP servers, and model gateways.

LLM systems are assembled from model provider SDKs, agent frameworks, MCP server implementations, model gateways, and supporting libraries. A dependency inventory records these components and their versions so that a known vulnerability or a compromised package can be traced to the systems that use it.

Risk condition. AI-specific dependencies are introduced without inventory, so a vulnerability disclosure in an agent framework or an MCP implementation cannot be mapped to affected systems.

Expected outcome. The components that compose LLM systems are inventoried at a version granularity that supports vulnerability and change tracking.

Assessment evidence

• Dependency manifests
• Agent framework and SDK versions
• MCP server implementation records
• Model gateway component records
• Container image contents

Implementation considerations. AI dependencies change quickly and are sometimes pinned to pre-release versions. Record the resolved versions in use rather than only the declared ranges.

Security objective. Assess the security risk of an LLM application based on its function, data exposure, integrations, and execution capability.

An LLM application risk assessment combines the sensitivity of the data it processes, the systems it can reach, the actions it can take, and the trust placed in its inputs. The result informs the depth of testing and the controls applied.

Risk condition. LLM applications are deployed at uniform assurance regardless of the data they process or the actions they can perform, so high-impact applications receive the same review as low-impact ones.

Expected outcome. Each LLM application has a recorded risk determination that reflects data exposure, integration reach, and execution capability, and that determination guides control selection.

Assessment evidence

• Application data flow records
• Integration and tool inventory
• Execution capability records
• Recorded risk determination

Implementation considerations. Risk changes when an application gains a new tool, a new data source, or a new agent capability. Reassessment should be tied to those changes rather than to a fixed calendar alone.

Security objective. Assess the exposure of model endpoints, including reachability, authentication strength, and the presence of test or administrative interfaces.

Model endpoint exposure describes the conditions under which an endpoint can be reached and used. It covers public and internal reachability, the strength of the access boundary, and the presence of development or administrative endpoints that were not intended for production traffic.

Risk condition. A model endpoint is reachable without an adequate access boundary, or a test, development, or administrative endpoint is exposed on a network segment that untrusted parties can reach.

Expected outcome. Model endpoint reachability and access boundaries are assessed and recorded, and endpoints without an adequate boundary are remediated.

Assessment evidence

• Endpoint reachability records
• Authentication and authorization configuration
• Gateway exposure configuration
• Rate and quota configuration

Implementation considerations. Rate control limits abuse but does not establish an access boundary. Treat quotas as supporting evidence alongside authentication and authorization rather than as a replacement for them.

Security objective. Analyze how an input source, an LLM application, an agent, its tools, and downstream systems combine into a reachable path to a sensitive operation.

AI attack path analysis treats the LLM system as a graph. It examines how an entry point, a prompt or content source, an agent, its available tools, the identity those tools run as, and a downstream system connect. The analysis identifies paths where untrusted input can reach a consequential operation.

Risk condition. Individual components are assessed in isolation, so a path that connects an untrusted input to a high-impact operation through an agent and its tools is not identified.

Expected outcome. Paths from untrusted input to consequential operations are identified and recorded, and the paths that carry the greatest impact are prioritized for control.

Assessment evidence

• Integration and tool graph
• Identity and permission records for tool execution
• Data flow records
• Recorded attack path analysis

Implementation considerations. The value of the analysis depends on accurate effective-permission data. A path is only as constrained as the identity its final tool call runs as.

Security objective. Assess the risk represented by an agent's effective execution capability rather than by its stated purpose.

An agent's risk is a function of what it can do, not what it is intended to do. Capability risk assessment records the tools an agent can invoke, the identity those invocations use, and the operations reachable through them.

Risk condition. An agent is assessed by its described role, while the tools and identities available to it permit operations well beyond that role.

Expected outcome. Agent risk is assessed against effective capability, and capability that exceeds the intended function is reduced or justified.

Assessment evidence

• Agent tool inventory
• Effective execution identity records
• Reachable operation records
• Recorded capability risk determination

Implementation considerations. Capability is often broader than intended because a tool inherits the permissions of the service identity behind it. Assess the service identity behind the tool as well as the tool description.

Security objective. Assess the security risk contributed by model providers, model artifacts, agent frameworks, MCP servers, and other AI system suppliers.

AI supply chain risk covers the providers and components an AI system depends on to function: model providers, model artifacts, SDKs, agent frameworks, MCP servers, and model gateways. Assessment considers the security ownership of each and the consequences of a compromise or a change.

Risk condition. AI system suppliers and components are adopted without assessment, so a compromised model artifact, framework, or connected server is not recognized as a security dependency.

Expected outcome. AI system suppliers and components are assessed before adoption and monitored over the relationship, with critical dependencies identified.

Assessment evidence

• Supplier and component inventory
• Provenance and integrity records
• Supplier assessment records
• Change and version records

Implementation considerations. AI supply chain risk overlaps general software supply chain risk but adds model artifacts and connected servers that execute or influence application behavior. Keep the assessment specific to those components.

Security objective. Preserve the application's control instructions when a user submits input intended to override them.

Direct prompt injection is input submitted by a user of the application that attempts to override the application's instructions or policy. The relevant boundary is between application-controlled context and user-controlled input. An LLM does not enforce an instruction hierarchy on its own, so the application cannot assume that its instructions take precedence over user text.

Risk condition. User input alters the application's intended behavior, causing it to disregard its instructions, disclose restricted context, or take actions outside its intended scope.

Expected outcome. The application's control instructions are preserved under adversarial user input, and deviations are detected.

Assessment evidence

• Prompt construction and context handling design
• Adversarial prompt test results
• Runtime prompt security events
• Instruction and policy separation records

Implementation considerations. Pattern filtering removes a subset of known phrasings and does not establish the boundary. Treat filtering as one supporting control alongside context isolation, output handling, and constrained execution.

Security objective. Preserve the application's control instructions when instructions are embedded in content the model reads, such as retrieved documents, web pages, or tool outputs.

Indirect prompt injection places adversarial instructions in content that the model consumes rather than in direct user input. Sources include retrieved documents, web content, files, and tool outputs. Because the application places this content into the model's context, retrieved content becomes an input trust boundary.

Risk condition. Content read by the model carries instructions that alter application behavior, and the application treats retrieved or tool-provided content as trusted context.

Expected outcome. Content consumed by the model is treated as untrusted input, and its influence on application behavior is bounded and observable.

Assessment evidence

• Retrieval and content ingestion design
• Content provenance records
• Adversarial content test results
• Runtime prompt security events

Implementation considerations. The exposure grows with the number of content sources an application reads and with the actions available once content is in context. Assess ingestion, retrieval, and the actions reachable afterward together.

Security objective. Protect the confidentiality of application-controlled instructions and the security-relevant behavior they encode.

System prompt exposure occurs through explicit extraction, partial disclosure, behavioral inference, error paths, logging, debugging interfaces, downstream tool context, and multi-turn leakage. Preventing literal disclosure of the system prompt and protecting the security-relevant application behavior it encodes are related but not identical objectives.

Risk condition. The system prompt is disclosed in full or in part, or its security-relevant contents are inferred, exposing embedded rules, references, or credentials.

Expected outcome. Application-controlled instructions are protected from disclosure, and security decisions do not depend on the secrecy of the prompt alone.

Assessment evidence

• Prompt handling and logging design
• Error and debug path review
• Extraction and inference test results
• Downstream context propagation records

Implementation considerations. A system prompt that carries a secret or a credential remains a risk even when literal extraction is prevented. Move security-relevant enforcement out of the prompt where the design allows.

Security objective. Maintain the application's safety and policy controls against inputs designed to circumvent them.

Prompt control bypass is the circumvention of an application's safety, policy, or guardrail controls through crafted input. The concern is whether the controls hold under adversarial conditions, independent of the specific phrasing used to test them.

Risk condition. Application controls that restrict behavior are circumvented through crafted input, so the application performs actions or produces output that the controls were intended to prevent.

Expected outcome. Safety and policy controls resist circumvention under adversarial input, and bypass conditions are identified and corrected.

Assessment evidence

• Guardrail and policy configuration
• Bypass test results
• Runtime policy enforcement events
• Control improvement records

Implementation considerations. A control that depends only on input pattern matching is bypassable by construction. Evaluate controls against a range of phrasings and encodings and treat single-pattern controls as incomplete.

Security objective. Prevent input in one user, session, or tenant context from influencing another.

Cross-context prompt manipulation covers cases where context, memory, or retrieved content from one user, session, or tenant influences another. It applies to shared memory stores, cached context, and multi-tenant retrieval where separation is assumed but not enforced.

Risk condition. Context or content from one user, session, or tenant reaches another, so the application acts on data outside the current requester's boundary.

Expected outcome. Context is isolated across users, sessions, and tenants, and cross-context influence is prevented and detectable.

Assessment evidence

• Context and memory isolation design
• Multi-tenant separation records
• Cross-context test results
• Runtime context access events

Implementation considerations. Shared memory and caching introduce cross-context paths that are invisible in a single-session test. Assess separation with concurrent, multi-identity scenarios.

Security objective. Control the sensitive data that enters prompts and is transmitted to model endpoints and providers.

Sensitive data reaches prompts through user input, application context, and retrieved content. It may include PII, credentials, API keys, internal documents, source code, customer data, regulated data, and security telemetry. The concern is the confidentiality of that data as it is transmitted to the model and processed by the provider.

Risk condition. Sensitive data is placed into prompts and transmitted to a model endpoint or external provider without a control that reflects its classification.

Expected outcome. The sensitive data that enters prompts is identified and controlled according to its classification and the destination that processes it.

Assessment evidence

• Prompt data flow records
• Data classification reaching model endpoints
• Provider processing terms
• Redaction and minimization configuration

Implementation considerations. The applicable controls differ between a self-hosted model and an external provider. Assess the destination and its data handling as part of the control decision.

Security objective. Control the disclosure of sensitive data in model responses returned to users or downstream systems.

Model responses can contain sensitive data drawn from training, retrieval, tool outputs, or context. The concern is the disclosure of that data to a recipient who is not authorized for it, whether an end user, a downstream system, or a log.

Risk condition. A model response returns sensitive data to a recipient that is not authorized for it, or to a downstream system or log that is not controlled for that classification.

Expected outcome. Sensitive data in model responses is controlled according to the recipient and the destination.

Assessment evidence

• Response handling design
• Output classification records
• Response monitoring events
• Downstream destination records

Implementation considerations. Output handling is a separate control from input handling. A response that is safe to return to one recipient may not be safe to write to a shared log or pass to another system.

Security objective. Control the retention of prompts and responses in application logs, provider logs, and analytics stores.

Prompts and responses are frequently retained for debugging, analytics, and model improvement. Retention creates data-at-rest that carries the sensitivity of the original content. The concern is the confidentiality and access control of that retained data.

Risk condition. Prompts and responses are retained in logs or analytics stores without controls that reflect the sensitivity of their content, or without a defined retention boundary.

Expected outcome. Retained prompts and responses are protected and access-controlled according to their classification, with a defined retention boundary.

Assessment evidence

• Prompt and response logging configuration
• Retention configuration
• Access control on log and analytics stores
• Data inventory for retained content

Implementation considerations. Retained prompt and response data often outlives the application that produced it and is copied into analytics pipelines. Follow the data to every store it reaches.

Security objective. Control the transfer of organizational data to external model providers and hosted AI services.

External model data transfer is the flow of prompts, context, and retrieved content to a provider outside the organization. The concern is the confidentiality of that data in transit, the terms under which the provider processes it, and the classification of what is sent.

Risk condition. Organizational data is transferred to an external provider without a control that reflects its classification or the provider's processing and retention terms.

Expected outcome. Data transferred to external providers is controlled in transit and governed by supplier terms appropriate to its classification.

Assessment evidence

• Outbound data flow records
• Provider agreements and processing terms
• Data classification per provider
• Transport protection configuration

Implementation considerations. The provider agreement is part of the control. Assess processing, retention, and sub-processor terms alongside the transport protection.

Security objective. Control the sensitive data that AI systems write to logs, traces, and telemetry.

AI systems generate logs, traces, and telemetry that can contain prompts, responses, tool inputs, credentials, and identifiers. The concern is the exposure of that sensitive data through logging that is broadly readable or retained without control.

Risk condition. AI logging and telemetry capture sensitive data that is then readable or retained without controls that reflect its sensitivity.

Expected outcome. AI logging captures the records needed for monitoring while sensitive content is controlled at generation and at rest.

Assessment evidence

• Logging and telemetry configuration
• Access control on log stores
• Sensitive field handling in logs
• Retention configuration

Implementation considerations. Logging that supports detection and logging that leaks sensitive data are in tension. Configure what is captured and who can read it as one decision.

Security objective. Maintain an inventory of the data sources indexed into retrieval pipelines and the classification of their content.

A RAG system answers using content retrieved from indexed sources. A data source inventory records which sources feed the index, who owns them, and the classification of their content, so that retrieval scope and authorization can be assessed against known sources.

Risk condition. Sources are indexed into a retrieval pipeline without an inventory, so the content that a model can retrieve and its sensitivity are not fully known.

Expected outcome. The data sources feeding retrieval are inventoried, classified, and attributed to owners.

Assessment evidence

• RAG data source inventory
• Content classification records
• Indexing pipeline configuration
• Source ownership records

Implementation considerations. Indexes accumulate sources over time and across teams. Reconcile the inventory against the indexing pipeline configuration rather than against documentation alone.

Security objective. Enforce that retrieval returns only content the requester is authorized to access.

Retrieval authorization determines whether a retrieval respects the requester's access rights. When authorization is applied at the application rather than at retrieval, a user can receive content through the model that they could not access directly.

Risk condition. Retrieval returns content without applying the requester's access rights, so a user obtains restricted content through generated answers.

Expected outcome. Retrieval enforces the requester's authorization, and access decisions are applied at retrieval rather than only at the application boundary.

Assessment evidence

• Retrieval authorization design
• Access control configuration on retrieval
• Tenant and user scoping records
• Authorization test results

Implementation considerations. Oversharing is often introduced when retrieval runs with a broad service identity. Assess the identity retrieval executes as, not only the application's front-door controls.

Security objective. Preserve the integrity of indexed content against malicious or unauthorized modification.

RAG poisoning is the introduction of malicious or misleading content into a retrieval source or index. It can occur through a compromised source, unauthorized document insertion, or the exploitation of a trusted-source assumption. Poisoned content can carry indirect prompt injection or bias generated answers.

Risk condition. Content in a retrieval source or index is modified or inserted by an unauthorized party, and the pipeline treats indexed content as trusted.

Expected outcome. The integrity and provenance of indexed content are protected, and unauthorized modification is detectable.

Assessment evidence

• Source provenance records
• Index write access controls
• Content change monitoring
• Re-indexing and validation records

Implementation considerations. Provenance and change monitoring matter because poisoning frequently exploits a source the pipeline already trusts. Assess integrity at the source and at re-indexing.

Security objective. Treat retrieved content as untrusted input to the model rather than as trusted context.

Retrieved content enters the model's context and can carry instructions, misleading data, or references that alter behavior. The trust placed in retrieved content is a security decision. Content that originates outside the organization or from user-writable sources warrants the same scrutiny as direct user input.

Risk condition. Retrieved content is placed into the model context as trusted, so instructions or data embedded in it influence application behavior.

Expected outcome. Retrieved content is handled as untrusted input, and its influence on behavior and actions is bounded.

Assessment evidence

• Retrieval handling design
• Content provenance and trust records
• Adversarial content test results
• Action constraints after retrieval

Implementation considerations. The risk is proportional to what the application can do after retrieval. Constrain the actions reachable once retrieved content is in context.

Security objective. Protect the vector store and its metadata from unauthorized access and modification.

A vector store holds embedded representations of source content along with chunk metadata. Exposure covers unauthorized read access to embeddings and metadata, unauthorized write access that supports poisoning, and network reachability of the store itself.

Risk condition. A vector store is reachable or modifiable without an adequate access boundary, exposing embedded content, metadata, or the index to unauthorized parties.

Expected outcome. Access to the vector store and its metadata is authenticated, authorized, and bounded to the systems that require it.

Assessment evidence

• Vector store access configuration
• Network reachability records
• Metadata handling records
• Store inventory

Implementation considerations. Chunk metadata can carry source paths, identifiers, and access hints that are sensitive independent of the embeddings. Assess metadata exposure alongside the embeddings.

Security objective. Maintain an inventory of MCP servers connected to LLM applications and agents, including their origin and the tools they expose.

An MCP server exposes tools, resources, and prompts to an LLM application or agent. An inventory records which servers are connected, where they originate, and what they expose, so that the capability reaching applications through MCP is known.

Risk condition. MCP servers are connected to applications and agents without an inventory, so the tools and resources reachable through MCP are not fully known.

Expected outcome. Connected MCP servers are inventoried and attributed to the applications and agents that use them, with their origin recorded.

Assessment evidence

• MCP server inventory
• Server origin records
• Tool and resource definitions
• Application-to-server mapping

Implementation considerations. MCP servers can be added by developers during integration work and can proxy to further servers. Reconcile the inventory against actual client configuration.

Security objective. Authenticate MCP servers and the connections to them, and manage the credentials involved.

MCP connections carry tool invocations that can reach organizational systems. Authentication establishes that a connection is to the intended server and that the server is authorized to be used. It covers the credentials the client presents, the credentials the server holds for downstream services, and the transport that carries them.

Risk condition. An MCP connection is established without authenticating the server or the client, or downstream credentials held by the server are not managed.

Expected outcome. MCP servers and connections are authenticated, and the credentials involved are managed and protected.

Assessment evidence

• MCP authentication configuration
• Credential management records
• Transport configuration
• Downstream credential inventory

Implementation considerations. The credentials an MCP server holds for downstream services are frequently more sensitive than the client connection. Assess both directions of authentication.

Security objective. Limit MCP-connected tools to the permissions and operations required by the approved use case.

MCP tools may expose file access, command execution, data retrieval, API operations, or administrative functions to an LLM application or agent. Tool availability alone is not sufficient evidence that the resulting execution boundary is appropriate. The effective permission of a tool is determined by the identity it runs as and the operations reachable through its parameters.

Risk condition. A connected MCP tool can perform operations outside the intended application scope, or permissions are not reviewed when server capabilities change.

Expected outcome. MCP tool capabilities and effective permissions are identified, reviewed, and restricted according to the approved system function.

Assessment evidence

• MCP server configuration
• Tool definitions
• Authentication configuration
• Effective service permissions
• Allowed operations
• External service access
• Change records

Implementation considerations. Tool permissions should be evaluated as effective permissions, not only as documented tool descriptions. Review the identity used by the MCP server, downstream service permissions, and operations available through parameterized tool calls.

Security objective. Establish the trust basis of an MCP server before connecting an application or agent to it.

Connecting to an MCP server extends application capability to whatever that server exposes and to whatever it can reach downstream. Connecting to a server whose origin, integrity, and behavior are not established places that trust in an unverified party.

Risk condition. An application or agent connects to an MCP server whose origin and integrity have not been established, or to a server that can change its exposed capability after connection.

Expected outcome. MCP servers are evaluated before connection, and connections are limited to servers with an established trust basis.

Assessment evidence

• Server origin and provenance records
• Integrity verification records
• Connection approval records
• Change monitoring configuration

Implementation considerations. An MCP server can present benign tool descriptions while its implementation reaches further systems. Establish trust from the server's origin and observed behavior.

Security objective. Preserve the integrity of MCP tool invocations against manipulation through model-generated parameters.

MCP tool calls are constructed from model output. When untrusted input influences that output, the parameters passed to a tool can be manipulated to reach unintended operations. The concern is the integrity of the tool invocation, including the operation selected and the parameters supplied.

Risk condition. Model-generated tool parameters are manipulated through untrusted input, causing a tool to perform an unintended operation within its available permissions.

Expected outcome. Tool invocations reflect the intended operation, and manipulation of parameters is constrained and detectable.

Assessment evidence

• Tool parameter handling design
• Invocation constraint configuration
• Tool invocation records
• Manipulation test results

Implementation considerations. A tool with broad parameters is manipulable even when its permissions are correct. Constrain the operations and parameter ranges a tool accepts, and record invocations for review.

Security objective. Detect changes to the tools, resources, and permissions an MCP server exposes.

An MCP server's exposed capability can change after connection through server updates, configuration changes, or dynamic tool registration. Capability change detection establishes that the tools and permissions in use match what was reviewed, and surfaces changes for reassessment.

Risk condition. An MCP server changes the tools or permissions it exposes after connection, and the change is not detected or reassessed.

Expected outcome. Changes to MCP-exposed capability are detected, recorded, and reassessed against the approved configuration.

Assessment evidence

• Baseline capability records
• Capability change records
• Change monitoring configuration
• Reassessment records

Implementation considerations. Capability change is a monitoring concern as well as a change-management concern. A server that adds a tool has changed the application's execution surface.

Security objective. Maintain an inventory of the tools available to each agent and the operations those tools expose.

An agent acts by invoking tools. An agent tool inventory records which tools each agent can invoke and the operations reachable through them, so that the agent's capability can be assessed against its intended function.

Risk condition. Agents are deployed with tool sets that are not inventoried, so the operations an agent can perform are not fully known.

Expected outcome. The tools available to each agent are inventoried and attributed to the operations they expose.

Assessment evidence

• Agent tool inventory
• Tool operation records
• Agent-to-tool mapping
• Tool source records

Implementation considerations. Tool sets change as agents are extended. Tie the inventory to the agent configuration that is actually deployed rather than to the intended design.

Security objective. Constrain the operations an agent can execute so that consequential actions occur within an approved boundary.

Agent tools can perform file operations, command execution, API actions, administrative operations, database actions, messaging actions, cloud operations, and identity operations. Unsafe tool execution is the ability of an agent to perform a consequential operation without a control appropriate to its impact.

Risk condition. An agent executes a consequential operation without an approval boundary, a constrained identity, an operation allowlist, or an observable record.

Expected outcome. Consequential agent operations occur within a defined boundary, run under a constrained identity, and are observable.

Assessment evidence

• Tool execution constraints
• Execution identity records
• Operation allowlists
• Tool execution records

Implementation considerations. Human approval is one boundary among several and is not always the right one. Constrained identities, operation allowlists, and observable execution can bound impact where approval is impractical.

Security objective. Align an agent's granted permissions with the operations its function requires.

Excessive agent permissions arise when the identity an agent uses can perform operations beyond the agent's function. The concern is the gap between granted permission and required permission, which determines the impact of a compromise or a manipulation.

Risk condition. An agent runs with an identity whose permissions exceed the operations its function requires.

Expected outcome. Agent permissions are scoped to the required operations, and excess permission is removed or justified.

Assessment evidence

• Agent execution identity records
• Granted permission records
• Required operation records
• Permission review records

Implementation considerations. Excess permission usually comes from reusing a broad service identity. Assess the effective permission of the identity behind the agent.

Security objective. Bound the volume, scope, and duration of the actions an agent can take without intervention.

An agent can take repeated or expanding actions in response to input or its own intermediate output. Unbounded action is the absence of limits on how many actions, of what scope, and over what duration an agent can take, which affects both security impact and resource consumption.

Risk condition. An agent takes actions without limits on volume, scope, or duration, so a single input can produce a large or expanding set of operations.

Expected outcome. Agent actions are bounded in volume, scope, and duration, and boundary conditions are observable.

Assessment evidence

• Action limit configuration
• Scope constraint records
• Agent action records
• Resource consumption records

Implementation considerations. Bounds serve both security and availability. Assess the limits on action count and scope alongside the resource and cost controls.

Security objective. Assign and authenticate distinct identities for agents so that their actions are attributable and access-controlled.

An agent that acts on systems does so under an identity. Agent identity and authentication establish that the agent presents a distinct, managed identity to the systems it reaches, so that its access is controlled and its actions are attributable.

Risk condition. An agent acts under a shared, unmanaged, or unauthenticated identity, so its access cannot be controlled and its actions cannot be attributed.

Expected outcome. Agents present distinct, managed identities that are authenticated to the systems they reach.

Assessment evidence

• Agent identity records
• Authentication configuration
• Credential management records
• Attribution records

Implementation considerations. A shared identity across agents removes attribution and makes least privilege impractical. Assign distinct identities where the systems support it.

Security objective. Identify paths where an agent connects an untrusted input to a consequential operation on a downstream system.

A cross-system agent attack path connects an entry point, an LLM application, a content source, an agent, its tools, an execution identity, and a downstream system into a reachable route to a consequential operation. The path analysis records how these elements combine and where impact concentrates.

Risk condition. An untrusted input reaches a consequential operation on a downstream system through an agent and its tools, and the path is not identified.

Expected outcome. Cross-system agent paths are identified and recorded, and paths carrying the greatest impact are prioritized for control.

Assessment evidence

• Agent tool and identity graph
• Downstream system reachability records
• Data flow records
• Recorded path analysis

Implementation considerations. Two paths illustrate the pattern. An untrusted retrieved document leads to indirect prompt injection, then to agent instruction manipulation, then to an MCP tool invocation under a service identity, then to an internal ticketing or source control operation. A user message leads to a tool call, then to a cloud operation under the agent identity, then to a configuration change. The impact of each path is set by the identity of its final operation.

Security objective. Monitor prompt flows for input that attempts to manipulate application behavior.

Prompt attack monitoring observes the input side of LLM traffic for manipulation attempts, including injection and control-bypass patterns. It provides the runtime signal that a point-in-time test cannot, because prompt content changes continuously in production.

Risk condition. Prompt manipulation attempts occur in production without a monitoring signal, so injection and bypass activity is not observed.

Expected outcome. Prompt flows are monitored for manipulation, and detected attempts are available for analysis.

Assessment evidence

• Prompt security event records
• Monitoring configuration
• Detection coverage records
• Model endpoint request records

Implementation considerations. Runtime monitoring does not replace architecture review. It observes what reaches the application; it does not establish whether the application's boundaries are correct.

Security objective. Monitor model responses for sensitive data disclosure and policy-violating output.

Model response monitoring observes the output side of LLM traffic for sensitive data disclosure and output that violates policy. It complements input monitoring because some concerns are only visible in the response.

Risk condition. Sensitive or policy-violating output is returned in production without a monitoring signal, so disclosure through responses is not observed.

Expected outcome. Model responses are monitored for disclosure and policy violation, and detected events are available for analysis.

Assessment evidence

• Response security event records
• Monitoring configuration
• Output classification records
• Log records

Implementation considerations. Response monitoring must be configured to avoid retaining the sensitive content it detects in a broadly readable store. Configure detection and retention together.

Security objective. Monitor changes to model, gateway, agent, and RAG configuration that affect the security boundary.

AI configuration change monitoring observes changes to model settings, gateway routing, agent policy, and RAG indexing that alter the security boundary. A configuration change can expand exposure without any change to code.

Risk condition. A change to AI configuration expands the security boundary without detection, so the exposure introduced by the change is not observed or reassessed.

Expected outcome. Security-relevant AI configuration changes are detected, recorded, and available for reassessment.

Assessment evidence

• Configuration change records
• Baseline configuration records
• Change monitoring configuration
• Reassessment records

Implementation considerations. Point-in-time testing does not replace change monitoring. A configuration that was assessed as sound can be changed the day after the assessment.

Security objective. Monitor connected MCP servers for changes to the tools and permissions they expose.

MCP capability change monitoring observes connected servers for changes to their exposed tools, resources, and permissions. Because a server can change its capability after connection, this monitoring maintains an accurate view of the execution surface reaching applications through MCP.

Risk condition. A connected MCP server changes its exposed capability, and the change is not observed against the approved baseline.

Expected outcome. Changes to MCP-exposed capability are monitored and available for reassessment.

Assessment evidence

• Baseline capability records
• Capability change events
• External service monitoring records
• Change monitoring configuration

Implementation considerations. MCP capability change monitoring overlaps external service monitoring where the server is operated by a third party. Include both the server behavior and the downstream services it reaches.

Security objective. Monitor agent tool execution for actions that fall outside expected operation.

Agent execution monitoring observes the operations agents perform through their tools, including the operation, the identity, and the outcome. It provides the record needed to detect and investigate agent actions that fall outside expected operation.

Risk condition. An agent performs operations that fall outside expected operation without a monitoring signal, so anomalous or unsafe execution is not observed.

Expected outcome. Agent tool execution is monitored, and operations outside expected behavior are available for analysis.

Assessment evidence

• Agent action records
• Tool execution records
• Execution identity records
• Monitoring configuration

Implementation considerations. Execution monitoring depends on the agent and its tools producing attributable records. Assess whether the execution path generates the records the monitoring requires.

Security objective. Correlate AI security events across prompt, response, tool, configuration, and identity sources.

AI security events originate from prompts, responses, tool executions, configuration changes, and identity activity. Correlation combines these sources so that a multi-step sequence, such as a poisoned retrieval followed by a tool invocation, can be understood as a single chain rather than as unrelated events.

Risk condition. AI security events are observed in isolation, so a multi-step sequence that crosses prompt, retrieval, tool, and identity sources is not recognized.

Expected outcome. AI security events are correlated across sources so that related activity is analyzed together.

Assessment evidence

• Event source inventory
• Correlation configuration
• Correlated event records
• Analysis records

Implementation considerations. Correlation quality depends on consistent identifiers across sources. Assess whether prompt, tool, and identity events can be joined on a common request or session identifier.

Security objective. Analyze AI security events to establish what took place and the root cause.

AI security event analysis establishes what happened during an AI security event and why. It draws on the correlated event record to determine the sequence, the entry point, the systems reached, and the underlying cause.

Risk condition. An AI security event is handled without analysis of what took place and why, so the root cause is not established and recurrence is likely.

Expected outcome. AI security events are analyzed to establish the sequence of activity and the root cause.

Assessment evidence

• Correlated event records
• Analysis records
• Root cause determination
• Impact records

Implementation considerations. Analysis depends on the evidence preserved at the time of the event. The quality of the analysis is bounded by the runtime and logging records available.

Security objective. Isolate a model endpoint to contain an active AI security event.

Model endpoint isolation removes or restricts access to an endpoint involved in an active event, containing the activity while analysis and remediation proceed. It is a containment action applied to the model interface.

Risk condition. An active event involving a model endpoint continues because there is no ready means to isolate the endpoint.

Expected outcome. A model endpoint involved in an event can be isolated to contain the activity.

Assessment evidence

• Endpoint isolation procedure
• Access control records
• Isolation action records
• Containment outcome records

Implementation considerations. Isolation is more effective when the endpoint's callers and dependencies are known in advance. The asset inventory and data flow records support a targeted isolation.

Security objective. Revoke an MCP connection and the associated credentials to contain an event involving a connected server.

MCP connection revocation removes a server connection and invalidates the credentials associated with it, containing activity that reaches systems through that server. It addresses both the connection and the downstream credentials the server holds.

Risk condition. An event involving a connected MCP server continues because the connection and its credentials cannot be revoked promptly.

Expected outcome. An MCP connection and its associated credentials can be revoked to contain an event.

Assessment evidence

• Connection revocation procedure
• Credential inventory
• Revocation action records
• Containment outcome records

Implementation considerations. Revoking the connection without invalidating the downstream credentials the server holds may leave the reachable operations available. Address both.

Security objective. Restrict an agent's tools or identity to contain an event involving agent activity.

Agent capability restriction reduces the tools available to an agent or constrains the identity it uses, containing activity that the agent is performing. It is a containment action applied to the agent's execution capability.

Risk condition. An event involving an agent continues because there is no ready means to restrict the tools or identity it uses.

Expected outcome. An agent's capability can be restricted to contain an event.

Assessment evidence

• Capability restriction procedure
• Agent identity and tool records
• Restriction action records
• Containment outcome records

Implementation considerations. The effectiveness of restriction depends on the agent's identity and tools being known and controllable at the time of the event. The agent inventory supports a targeted restriction.

Security objective. Investigate a prompt security incident using preserved prompt, response, and execution records.

Prompt security incident investigation reconstructs a prompt-related event from the preserved records of prompts, responses, and the actions that followed. It establishes what input was involved, how the application responded, and what operations resulted.

Risk condition. A prompt security incident cannot be reconstructed because the prompt, response, and execution records needed for investigation were not preserved.

Expected outcome. Prompt security incidents can be investigated from preserved records, and the sequence of activity is established.

Assessment evidence

• Preserved prompt and response records
• Execution records
• Investigation records
• Triage and validation records

Implementation considerations. Investigation depends on records that may themselves contain sensitive content. Preserve the records under access control appropriate to their sensitivity.

Security objective. Preserve AI security event data and metadata with integrity and provenance for analysis and investigation.

AI security evidence preservation retains the prompt, response, tool execution, configuration, and identity records associated with an event, along with their metadata, so that analysis and investigation can rely on them. Preservation addresses both the completeness and the integrity of the records.

Risk condition. The records needed to analyze and investigate an AI security event are not preserved, or their integrity and provenance are not maintained.

Expected outcome. AI security event data and metadata are collected and preserved with integrity and provenance.

Assessment evidence

• Evidence collection procedure
• Record integrity controls
• Provenance records
• Retention configuration

Implementation considerations. Evidence quality matters when the mapping is used for control review as well as for incident response. Records that lack integrity or provenance limit both analysis and assurance.