AI Agent Security: 9 Checks Before You Grant Access

Quick answer

AI agent security means controlling what an AI system can read, change, remember, and send through connected tools. Before granting production access, check ownership and identity, permissions, connected tools, approvals, prompt injection defenses, logs, memory, the stop procedure, and retesting after changes. Ask your MSSP to demonstrate these controls using your actual workflow.

The useful question is simple: What could this agent do if it followed the wrong instruction?

Bring that question to the next pilot review. Follow it through to the connected systems, where a wrong instruction could become a real transaction.

Why AI agent access deserves its own review

On August 4, 2026, Microsoft expanded its Zero Trust assessment and workshop guidance with additional AI checks and controls for AI memory. That update gives buyers a timely reason to revisit the permissions behind agent pilots. Read Microsoft's announcement.

Consider this hypothetical example. A customer-service agent reviews support cases and recommends service credits. Its pilot looks excellent, so someone connects the billing system. Now the team needs to decide whether the agent can merely suggest a credit, prepare one for approval, or issue it independently.

Those are three different levels of authority. Put the agreed limits in the statement of work before anyone approves the integration.

If you are assigning responsibilities between internal IT and an outside provider, start with what an MSSP does. Then add the following checks to your agent deployment review.

AI agent security checklist: 9 checks before production

Use these nine checks to decide what needs fixing before launch. Adjust the requirements to the sensitivity of your data and the consequences of each action.

1. Give every agent an accountable owner and distinct identity

Record the business sponsor, technical owner, purpose, environment, and next review or retirement date. Use a distinct identity to trace activity and limit disruption to other workloads when suspending that agent.

Microsoft recommends unique agent identities, named sponsors, and production credentials that avoid stored client secrets where supported. Microsoft Entra Agent ID best practices explain its platform-specific approach.

Ask for evidence: An inventory entry and a sign-in record for your agent. Have the provider show which identity it would suspend if that agent caused a problem.

2. Review permissions in the system receiving the request

Write down exactly which records the agent can access and which operations it can perform. When it acts for a person, verify that it cannot use broader service-account permissions to bypass that person's access limits. For the service-credit example, reading a support case should not automatically grant permission to change every customer's billing details.

OWASP identifies unnecessary capabilities, excessive permissions, and excessive autonomy as causes of damaging agent actions. It recommends enforcing authorization in downstream systems. See OWASP's excessive agency guidance.

Ask for evidence: A rejected request against an out-of-scope record, with the enforcing policy visible.

3. Check every connected tool separately

A tool connection can bundle several operations. Request an inventory showing which are enabled, their allowed destinations, and who approves changes. Pay particular attention to connectors that can run code or modify records.

OWASP recommends restricting tools and their permissions to the task. Its AI Agent Security Cheat Sheet also covers approvals, monitoring, and adversarial testing.

Ask for evidence: A demonstration that an unapproved operation is blocked. Include tool configuration review when comparing cloud security providers.

4. Require clear approval before high-impact actions

Decide which actions require a person: granting access, sending sensitive information, deleting records, or issuing credits above your chosen limit. Enforce approval before execution, with the actual recipient, amount, and affected records visible.

For our hypothetical service-credit agent, a reviewer should see the customer account and proposed credit together. A generic "continue" button would make a poor approval record.

Ask for evidence: A pending request that stays pending when nobody approves it, plus a demonstration that changing its details requires fresh approval.

5. Test prompt injection through ordinary business content

Prompt injection can arrive inside material an agent reads, including documents, emails, and tool responses. The attacker does not need to sit at the chat window. OWASP's prompt injection guidance describes these indirect attack paths and layered defenses.

Use an authorized test environment with synthetic data. Put a harmless conflicting instruction inside a sample support attachment, then observe whether the workflow changes.

Ask for evidence: The test trace showing what the agent attempted and what happened. If it refuses the instruction before calling a tool, separately test that the tool rejects an unauthorized request. A model's reassuring explanation is not proof that the integration enforced policy. Repeat with several scenarios; one blocked prompt is not a complete security assessment.

6. Require logs that explain attempted and completed actions

Capture the agent identity, connected tool, target resource, timestamp, result, and approval reference where applicable. Include denied and failed requests so analysts can investigate attempts that did not produce a business transaction. Agree on redaction and retention so security logs do not become an unnecessary store of customer data.

Ask for evidence: Have the provider reconstruct one sample service-credit transaction from its logs. Can an analyst identify what changed and who approved it without asking the developer to interpret a chat transcript?

Define ingestion and investigation scope with your managed SIEM provider.

7. Control what the agent remembers

Memory can influence later sessions, which means deleting the original conversation may not remove every retained instruction. Microsoft recommends controls over memory writes, separation between users and tenants, provenance, and deletion. Read its agent memory security guidance.

Ask for evidence: A walkthrough showing where remembered customer information lives, who can retrieve it, and how an authorized administrator corrects or removes it. Include a rejected attempt to retrieve another test customer's private memory without permission. If memory is disabled, document that configuration and who can enable it.

8. Rehearse stopping the workflow

Agree on who can pause the agent, restrict its connectors, and investigate affected business records. Include a backup contact outside normal working hours.

Ask for evidence: A tabletop exercise starting with an unexpected credit. Ask the team to name the first system it would open, the first person it would call, and the evidence it would preserve. Follow the tabletop with an authorized test using synthetic data. Check whether queued work, connector credentials, and existing sessions remain usable after the stop procedure, and record any delay before access ends. Do not assume one switch stops everything immediately.

Add this scenario to your incident response provider discussion.

9. Retest when tools or access change

Record the model, tools, permissions, and configuration used during testing. Decide which changes trigger another review. Adding a billing connector should reopen the approval decision even if the agent's name and interface stay the same.

Ask for evidence: A release record linking the deployed configuration to the latest test results. Ask the provider to explain how an urgent change will receive review when the usual approver is unavailable.

What should you ask an MSSP about AI agent security?

Bring a real workflow to the sales meeting and use three questions:

• Which of these nine controls will you operate, and which belong to our application team?
• What evidence will we receive after onboarding and after a material change?
• Can you demonstrate one blocked action, one approved action, and one incident investigation?

Score answers in the MSSP evaluation checklist. For every missing demonstration, record who will provide it and when. That gives you a concrete follow-up after the sales call.

Frequently Asked Questions

Is an AI agent security review different from a chatbot review?

Yes, when the agent can use connected tools or retain information across sessions. The review must cover the actions and data available through those integrations, alongside the quality and safety of its answers.

Does read-only access make an AI agent safe?

No. Read-only access limits changes to the connected system, but the deployment still needs controls over which information it retrieves, who can request it, and where its output goes. Review the complete workflow.

Can an MSSP secure every AI agent we deploy?

Coverage depends on the provider's expertise, supported platforms, available telemetry, and contract. Ask it to identify unsupported connectors and missing logs. Require named owners for the remaining controls before granting access.

Choose one agent and prove the controls

Start with the pilot closest to production. Run these checks with its owner and your security provider, then record the unresolved items and deployment decision. Share that evidence with the next team requesting an agent integration.

If you need outside help, compare MSSPs by service and platform and give shortlisted providers the same workflow to assess.