Is Your AI Assistant Safe? Three Security Questions Every Leader Should Be Asking

The newest generation of AI assistants does not just suggest what to do. It does it. Tools like Claude Code, GitHub Copilot's coding agents, and the latest IDE-embedded AI helpers now run shell commands, edit files, send emails, query customer records, and call into your business systems on a user's behalf. That shift from AI that recommends to AI that acts is the single biggest change in how this technology touches your organization, and it is one most companies have not fully reckoned with from a security standpoint.

At Scalesology, we hear three security questions from leaders almost every week, and they all deserve clear answers before you put an agentic AI tool in front of your team:

1. What stops the AI from doing damage?

2. What stops the AI provider from leaking the data we send it?

3. What stops a teammate from reaching my sensitive data or my elevated access through the AI?

The good news is the answers are knowable and the controls are real. The less-good news is that the protections are not where most leaders assume they are. Let's walk through them.

Start with the Architecture to use your AI Assistant securely

To answer any of those three questions, you need a basic mental model of how an AI assistant actually works when it takes an action on your behalf:

1. You type a prompt into your local client: Claude Code, your IDE, the chat window.

2. The local client adds context including a system prompt, the list of tools it has available, and sometimes recent conversation history, then sends the whole package over an encrypted connection to the AI provider.

3. The AI responds with either an answer or a request to call a tool: run this shell command, read this file, look up this Jira issue.

4. The local client executes the tool, usually after asking the user to approve, depending on the tool and the user's permission settings.

5. The tool's result is sent back to the AI, which then either responds with another tool request or returns a final answer.

6. Loop until done.

The most important observation in that flow is this: the local client is driving the loop. The AI in the cloud is a stateless reasoning engine. It receives a prompt, returns either an answer or a tool request, and waits. It holds no session, no memory between calls, and no knowledge of what your colleague's AI is doing across the hall. Every piece of context the AI sees on a given turn was sent to it by the local client on that turn.

That single fact, that the AI is stateless and the client is in charge, is the foundation under all three of the questions below.

Question 1: What Stops the AI from Doing Damage?

The AI never executes anything directly. It can only ask the local client to run a tool. Whether the tool actually runs is a decision your local client makes, governed by two things you can control.

Permission settings in the local client. Tools like Claude Code prompt the user before running shell commands, editing files outside the working directory, or writing to disk. Permissions can be configured per-tool, per-command pattern, or session-wide, and pre-set in configuration files at the user, project, or enterprise level. An organization can pre-approve safe read-only operations like git status and require explicit consent, or outright block, destructive ones like rm -rf, git push --force, or anything that touches production.

The scope of the connected tools. Modern AI assistants extend their capabilities through Model Context Protocol (MCP) servers, small adapters that expose specific operations to the AI. The key word is specific. A read-only Outlook adapter can let the AI read mail but not send it. A Jira adapter connected with a read-only token cannot transition tickets. The AI's blast radius is the union of what your client allows and what your connected tools expose. Never more.

What this means in practice: the strongest control is not a fancy AI safety feature. It is the same thing that protects you from any other software: least-privilege configuration. Choose your AI's connected tools deliberately. Issue them credentials with the smallest scope they need. Lock down dangerous permissions at the enterprise level instead of asking every individual user to make the right call in the moment.

Question 2: What Stops the AI Provider from Leaking My Data?

When your prompt leaves the local client and reaches Anthropic, OpenAI, or whichever AI provider you're using, it is in the provider's hands. Three things govern what they can do with it.

The contract. Commercial API terms from major providers commit that customer inputs are not used to train models and are retained only as needed to deliver the service. This is the same kind of protection you already rely on for Microsoft 365, Google Workspace, or Salesforce. It is a contractual commitment backed by SOC 2, ISO 27001, and similar third-party audits. It is not a technical guarantee, but it is the kind of assurance enterprise buyers have relied on for cloud services for two decades.

Encryption in transit. All traffic between your client and the AI provider is encrypted with HTTPS. The provider sees plaintext only after it terminates the connection inside its own infrastructure.

Private-cloud deployment. For the highest-sensitivity workloads, you can move the AI out of the vendor's environment entirely. Running Claude through AWS Bedrock, or other models through Google Vertex or Azure OpenAI, puts the model inside a tenant you control. Anthropic the company never sees your prompts in that scenario. The model weights are served from infrastructure you operate. This is the strongest technical protection available today, and it comes at meaningfully higher cost: typically two to three times the standard API price, plus integration work and capacity planning.

The honest middle ground is this: for most internal business work including coding, drafting, research, and ops automation, commercial API terms are appropriate and proportionate to the risk. For regulated data such as PHI, ITAR, or certain financial categories, or for material non-public information, the additional investment in a private-cloud deployment is the right call. Where you draw that line should be a deliberate decision, not an accident of which tool a developer downloaded first.

Question 3: What Stops Others from Reaching My Data Through the AI?

This is the question that catches people most off guard, because the intuitive answer is wrong.

The intuition goes something like this: if I use my AI assistant to read my email all day, does it know what is in my email? And if it knows, can a teammate's AI leak that to them?

Return to the architecture. The AI is stateless. When your teammate asks their AI assistant what emails Ken sent today, four things happen:

1. The teammate's local client sends their prompt, not yours, to the AI.

2. The AI asks the teammate's tools to look up the emails.

3. Those tools run with the teammate's credentials and cannot see your mailbox.

4. The AI has no memory of your previous session to leak from.

Even on web-based AI products, the chat history is held by the web application scoped to your individual account, not by the AI model itself. The model is stateless. The web app is the stateful part, and it follows the same multi-tenant SaaS isolation rules as any other web product you trust today.

But there is an important exception, and it is the one your IT and security teams need to think hardest about: shared tools.

If your organization deploys a connected tool that exposes a shared resource such as a corporate knowledge base, a team Slack archive, a shared SharePoint library, or a CRM, then any user whose AI assistant can reach that tool can query it through the AI. The AI becomes a natural-language interface to whatever the shared tool is willing to return. That is exactly what a corporate knowledge base is meant to enable. The risk is when shared tools do not enforce the same per-user permissions internally that they would in their normal user interface.

The practical implications:

• Inventory your AI-connected tools the way you inventory SaaS applications. Know which are local-per-user such as someone's personal Outlook or an individual's time-tracking tool, and which are shared such as a corporate knowledge base, team Slack archive, or CRM.

• Use the tool's own authentication and authorization to enforce per-user data access on shared servers. Do not rely on the AI to ask only for what is appropriate. The AI has no concept of organizational policy unless the connected tool enforces it.

• Audit access logs on shared tools the same way you audit access to the underlying systems they wrap.

The AI is a passthrough. The connected tool is the policy enforcement point. Get the tool's permissions right and the AI inherits them. Get them wrong and the AI becomes the most efficient way for someone to exploit the mistake.

Where to Start

If your organization is rolling out, or quietly already using, agentic AI tools, here is the short version of what to do this quarter:

1. Inventory which AI assistants are in use and which connected tools, plugins, or extensions are hooked up to them. You probably have more in your environment than you think.

2. Categorize each connected tool as local-per-user or shared. Treat shared tools the way you would treat any shared system that exposes sensitive data. They need proper authentication, authorization, and audit logging.

3. Standardize permission settings in the client tools so destructive operations require explicit consent, or are blocked outright, without relying on individual user judgment in the moment.

4. Decide where regulated or high-sensitivity workloads need to run, whether that is commercial API or private-cloud deployment, and make that an explicit policy rather than leaving the call to each team.

5. Train your users on how the AI loop actually works, so they understand that approving a tool call is the security boundary and that shared tools really do mean shared.

The architecture is simpler than it looks once you have seen it: the AI is a stateless reasoning engine, the local client is the security boundary, and the connected tools are the policy enforcement points. Investments in AI security should land at the client and tool layers. The model itself is not where the controls live.

Getting this right is not a one-time audit. It is an ongoing discipline. The organizations that approach agentic AI with the same rigor they bring to any other enterprise software are the ones that capture the productivity gains without opening new doors for risk.

How Scalesology Can Help

At Scalesology, we help growing businesses adopt AI safely and productively, without security being the reason it does not happen. We work alongside your team to inventory your current AI footprint, identify the tools and integrations that need stronger controls, design the right enterprise-wide permission and deployment policies, and choose the right balance between commercial API access and private-cloud deployments for your workload mix.

If you are starting to bring AI assistants into your business and want to do it the right way, or you have already deployed them and want a second set of eyes on the security picture, let's talk. Contact us today to schedule an AI security readiness conversation.