Agentic AI security is the practice of controlling what an AI system can access and do as it plans tasks and uses tools. For vendor risk teams, the central question is practical: which actions may a supplier’s agent take with your data, systems or business authority, and how are those limits enforced?

A support agent might read a ticket, look up an account and propose a response. The same workflow could also send messages, change customer records or issue a refund. Each additional action changes the risk of the integration, even if the underlying model stays the same.

This playbook focuses on access and execution controls for vendor-provided agents. It complements broader AI vendor risk management by turning an approved use case into specific permissions, release conditions and shutdown procedures.

Map the workflow before approving the integration

Ask the service owner and vendor to walk through one real task from start to finish. Identify what starts the task, which information enters the agent’s context, which systems it queries and what it can change. Include the tools and other agents it can call.

Keep a record of the actual deployment you are approving:

• The agent’s business purpose and internal owner
• The vendor, product and enabled features
• The identities used to access each connected system
• The data sources, destinations and retention arrangements
• The available actions and their approval requirements
• The model, tool and configuration versions covered by testing

A vendor’s platform may support many workflows. Your approval should identify the subset your organization intends to use. If a later release adds a new connector or enables autonomous action, the service owner should be able to see that it falls outside the previous decision.

Create an action and permission matrix

Describe permissions using concrete verbs and targets. “Access to CRM” is too broad for a useful review. “Read the contact fields on assigned support cases” gives an administrator something specific to configure and test.

For a hypothetical support deployment, the starting matrix might be:

• Read: retrieve approved knowledge articles and the current customer’s support record, with access limited to the relevant tenant and case.
• Draft: prepare a response or proposed record update in a review area.
• Send or change: submit a customer message or update a case only after the designated reviewer approves the specific operation.
• Restricted: bulk export, account deletion, changes to permissions and payment actions remain unavailable in the initial deployment.

These are example deployment choices, not universal rules. A different service may justify different autonomy. The decision should reflect the data, possible consequences, reversibility and effectiveness of the available controls.

OWASP describes excessive agency as a risk arising from excessive functionality, permissions or autonomy. Its guidance supports limiting available tools and enforcing authorization in downstream systems. Use that distinction during review: a prompt telling an agent to avoid an operation does not demonstrate that the integration cannot execute it.

Verify the enforcement point

Ask where a proposed tool call becomes an authorized operation. The answer should identify a component outside the model’s generated text, such as the destination system’s access controls or an independently enforced policy service.

Request a demonstration using the identity intended for production. Test one allowed action and one denied action against the same target system. Check permissions at the resource level and verify that removing a tool from the interface has not left another route to the same operation.

AWS’s AgentCore policy documentation illustrates an important distinction: listing a tool and authorizing an actual invocation are separate decisions, and invocation authorization considers the request’s parameters. Whatever technology your vendor uses, ask it to demonstrate that the actual request is checked.

Treat retrieved content as an untrusted input

An agent may encounter instructions inside tickets, documents, websites or tool responses. Those instructions can conflict with the user’s task or try to redirect the agent toward another action. OWASP’s prompt injection guidance explains this risk and recommends layered controls, including restricted privileges and approval for high-risk operations. It does not claim that a single filter can eliminate prompt injection.

Make testing specific to the workflow. In a safe test environment, place a misleading instruction in a sample ticket asking the agent to send the case history to an unrelated address. The expected result should cover both behavior and execution: the agent should disregard the instruction, and the system should prevent an unauthorized transmission if the model nevertheless requests one.

Also test a retrieved document that impersonates an internal administrator. Check whether the integration treats the document as evidence to read rather than authority to change access. Preserve the inputs, observed tool requests and destination-system results so the review can distinguish a persuasive answer from an enforced boundary.

Make human approval specific and reviewable

An approval screen should show the action that will actually execute. For a customer message, show the recipient and final content. For a record change, show the target and changed fields. Material changes after approval should require another review.

Ask the vendor to demonstrate what happens when approval expires, the reviewer declines or the network retries a request. A person approving one action should not unknowingly authorize repeated or broader operations.

The OWASP AI Agent Security Cheat Sheet recommends binding approvals to exact actions and independently validating execution. For your deployment, turn that guidance into observable acceptance criteria. For example: a changed recipient blocks sending, a rejected request stays blocked, and a retry cannot silently create a duplicate action.

Release the agent in bounded stages

A staged release makes it easier to locate failures before expanding access. Start with a test environment and representative, appropriately protected data. Then consider a limited read-only pilot, followed by drafting for review. Add execution rights only when the business owner and security team have accepted the evidence for that action.

For each stage, record the tested scope, expected behavior, unresolved issues and the person who approves advancement. Include normal tasks, ambiguous requests, permission failures and unavailable dependencies. A successful demonstration of the ideal workflow is only one part of the evidence.

Set clear hold conditions. Examples include a cross-tenant data response, an unexplained permission expansion or a failed stop test. Fix the issue and repeat affected tests before progressing. This gives procurement a concrete approval record and gives the vendor a clear path to resolve the blocker.

Test stopping and recovery before they are urgent

Identify who can disable the agent, revoke its connected access and stop queued work. Determine whether actions already sent to downstream systems can be canceled, reversed or only investigated. A stop button’s effect should be demonstrated for the actual workflow.

Run a controlled exercise: start a non-destructive task in a test environment, stop the agent and check for subsequent tool calls and queued actions. Verify that relevant credentials or grants can be revoked through the supported administration path. Record any delay or residual access.

NIST’s AI Risk Management Framework includes mechanisms to disengage or deactivate systems, regular monitoring of third-party AI risks, and post-deployment response and recovery planning. These are useful governance outcomes to translate into vendor-specific operating procedures.

Keep approval tied to the current deployment

After launch, review changes that affect the original boundaries: new tools, broader scopes, different data sources, model changes, new destinations or a switch from reviewed actions to automatic execution. Decide which changes need notification and which require approval before use.

Monitor attempted and completed actions, denied requests, unexpected destinations and approval failures. Retain enough information to investigate the outcome while controlling access to logs and avoiding unnecessary sensitive content. Agree with the vendor who investigates which events and how evidence will be provided.

In the support example, adding a refund tool would trigger a new review of financial limits, authorization and duplicate prevention. A model update might instead require targeted regression tests. Recording the reason for each decision keeps the process proportionate to the change.

Bring the access decision into vendor risk management

Agentic AI security works best when the technical configuration and the vendor approval record describe the same deployment. Keep the workflow map, permission matrix, test evidence and operating owners together so they can be revisited at a change or renewal.

Findings’ AiVRM offering focuses on AI-related vendor exposure. Use this playbook to frame a discussion about the evidence and oversight your organization needs, including the controls that remain the responsibility of the vendor and your own system administrators.