The questions your security team will ask about AI tools

A security review is harder when the request is broad and the data flow or permissions are unclear. Make the proposed use concrete so the reviewers can assess it.

Here are questions to prepare, including three useful starting points. Approval depends on the organization’s requirements and evidence, not on answering a universal set of deciding questions.

Three questions to start with

Where does our content go, and for how long? Not “is it secure” — specifically: which content leaves our network, to which provider, retained for how long, and used for what. The answers differ sharply between consumer plans, business plans and API access, and the difference is usually the whole conversation. Get this in writing from the vendor’s documentation rather than from a salesperson.

What identity does it act as? Check how logs distinguish the person, application, delegated permissions and individual run. Acting under a user’s authorization does not automatically destroy attribution; dedicated service identities also need appropriate ownership, scope and audit records.

What can it do without a person? Read-only is one risk profile. Writing, sending, deploying or paying is another entirely. Acting on a schedule or an external trigger is a third, and it is a governance question rather than a tooling one. Draw this boundary as a list of systems and verbs, not as a principle.

These answers define part of the review. Add the controls, contractual requirements and tests appropriate to the data and actions involved.

The rest of the list

Is our content used for training? Verify the exact product, plan, settings and contract. Training use, operational retention and connected-tool handling are separate questions; do not infer all three from a business-tier label.

Who can access logs and stored content? Identify which prompts, outputs, tool results and metadata are retained, if any, who can access them, and the applicable deletion and monitoring rules.

Where is it processed geographically? Matters for data residency obligations, and the answer varies by plan and region.

What happens if we leave? Export, deletion, and how you verify deletion actually occurred.

How do we turn it off in a hurry? Who can revoke access at three in the morning without a vendor support ticket. Genuinely worth knowing before you need it.

What is logged on our side? If you cannot reconstruct what the tool did last Tuesday, you have an experiment rather than a controlled deployment.

What happens when it is wrong? Document detection, reversibility, escalation and responsibility. Test the relevant failure paths rather than relying only on a success demonstration.

The risk people miss

Data disclosure and action authority are different risks, and either may dominate a particular deployment. Review both when an agent can use credentials inside your environment.

Self-hosted execution does not automatically resolve residency or confidentiality. For example, Cursor documents local tool execution with cloud inference and planning, plus transmission of relevant content and artifacts. Review the full data path as well as the worker’s permissions.

Review its identities, permissions, network access, data handling and recovery as you would other privileged software. Scope access to the required task rather than starting with a broadly privileged service account.

Why these reviews stall

Three fixable causes.

The request is too broad. Define the specific product, environment, repositories, allowed actions, test period and review owner. That gives reviewers a concrete proposal without assuming it can be approved immediately.

Ownership is unclear. Name the decision maker and the evidence they need. A review can also be blocked by substantive technical or contractual issues; a deadline does not remove them.

The answers are marketing. “Enterprise-grade security” tells a reviewer nothing and slightly annoys them. Link the vendor’s own documentation on retention and training, and say plainly where you could not find an answer.

Check the existing baseline

Worth raising, because it changes the framing from “should we allow this” to “what are we already exposed to”.

Establish whether unapproved usage is occurring in your organization and what data it involves. Do not assume it exists everywhere or that every personal account has identical controls.

A controlled deployment may reduce some existing exposure, but can introduce new access and automation risks. Compare both with evidence rather than using possible shadow usage as an automatic approval argument.

Three answers that should worry you

Not every vague answer is a problem. These three are.

“It depends on your configuration” without the configuration. Ask for documented defaults, required settings and a way to verify them. Missing detail does not tell you whether a safe configuration exists.

“We do not retain data” without scope. Ask which data, endpoints, subprocessors and exceptions the statement covers. Distinguish training, abuse-monitoring logs, application state and backups; some configurations offer restricted retention, but eligibility and exceptions matter.

No documented failure response. Ask how errors are detected, contained and recovered, and what you must implement yourself. A missing answer is an unresolved requirement, not evidence about the vendor’s other customers.

A note on shadow usage

Before the review concludes, it is worth establishing what is actually happening now — not as an enforcement exercise, but because it changes what you are comparing against.

Use a proportionate, privacy-aware way to establish current usage and let people report mistakes safely. Compare the proposed deployment with the actual baseline you find.

That comparison can make the decision more concrete. It does not guarantee a faster approval or replace the controls the proposed deployment requires.

What to bring to the meeting

One page. The named systems. The identity and its permissions. What runs unattended and what does not. What is logged, where, and for how long. The end date and who reviews it. The vendor’s own documentation links for retention and training. And the honest list of what you could not find out.

That last item earns more credibility than anything else on the page, because a reviewer who finds a gap you did not disclose will discount everything else you said.

Technical review, October 10, 2026. References: Cursor: Self-Hosted Machines; OpenAI: API data controls; NIST: AI Risk Management Framework.

Try this

For one tool, map data destinations and retention, identity and permissions, and allowed unattended actions. Record the product, plan and settings, link the supporting documentation, and mark unresolved requirements for the responsible reviewers.