Before You Connect AI Agents to Your Business Systems: A Guardrails Checklist

The Short Answer

Yes, most businesses should adopt AI agents, but only at the level of access their identity, data, and logging controls can actually support. The headline risk of 2026 is not that an AI model says something wrong. It is that an agent with real credentials does something wrong: it forwards a privileged email, deletes a folder, approves an invoice, or follows instructions hidden in a document it was asked to summarize.

That risk has moved from theory to the news. This fall, the Los Angeles Times and CNN both reported on Nvidia launching tooling to keep AI agents in check after agents were used to break into companies. Vendors are building guardrails because the default setup has too few of them. Your job as the buyer is to decide how much autonomy to grant, and to make sure the plumbing underneath (permissions, data classification, logging, and a human approval step) is ready before you connect anything.

This guide walks through that decision: what an agent actually is, the specific ways agents fail, the four deployment levels you can choose between, and a practical checklist for Los Angeles firms, especially law and professional-services firms with confidentiality duties.

What Changed: Assistants Answer, Agents Act

A chat assistant takes a prompt and returns text. An agent takes a goal, decides on steps, and calls tools to carry them out: searching your SharePoint, sending mail through Outlook, updating a CRM record, or running a script. Protocols such as the Model Context Protocol have made it much easier to plug an AI model into business systems, which is why agent features are appearing in nearly every SaaS product your staff already uses.

That convenience changes the security model in three ways:

• The agent inherits a person’s or a service account’s permissions. Whatever that identity can reach, the agent can reach, at machine speed.
• The agent reads untrusted content. Every inbound email, shared PDF, and web page is a potential set of instructions.
• The agent’s actions look legitimate in logs. A file deleted by an agent running as your paralegal looks like a file deleted by your paralegal.

The data suggests most organizations have not caught up. IBM’s Cost of a Data Breach Report 2025 found that 13% of organizations reported breaches of AI models or applications, and 97% of those breached organizations lacked proper AI access controls. The same report found 63% of breached organizations had no AI governance policy or were still developing one, and put the global average cost of a breach at $4.44 million.

The Four Ways Agents Go Wrong

The OWASP Top 10 for LLM Applications is the most widely used industry catalog of these risks. For a business buyer, four failure modes matter most.

1. Prompt injection. An attacker hides instructions in content the agent reads, such as white text in an email or a comment in a shared document, telling it to export contacts or forward a thread. OWASP ranks prompt injection as LLM01, its top risk, and notes there is no fool-proof prevention today. You mitigate it by limiting what the agent can do, not by hoping the model will refuse.

2. Excessive agency. OWASP’s LLM06: Excessive Agency describes agents that have more functionality, permissions, or autonomy than the task needs. An agent built to summarize the inbox that can also send and delete mail is the textbook case.

3. Oversharing through existing permissions. Microsoft states that Microsoft 365 Copilot only surfaces data the individual user already has permission to access. That is the right design, but it means years of ‘Everyone’ links and overly broad SharePoint sites suddenly become searchable in plain English. The agent does not create the exposure. It makes the exposure trivially easy to find.

4. Credential and token sprawl. Agents authenticate with API keys, OAuth grants, and service accounts. These are frequently created by a single enthusiastic employee, never reviewed, and never expire. Verizon’s 2025 Data Breach Investigations Report found third-party involvement in breaches doubled to 30%, and every agent connector you authorize is another third-party path into your tenant.

Choosing Your Deployment Level

Not every agent needs the same scrutiny. The right question is not whether to use AI, but which level of autonomy each workflow deserves. Most firms should run several levels at once: broad access to low-risk assistants, and tightly controlled pilots for anything that writes, sends, or deletes.

Deployment level	What it can do	Primary risk	Controls required first	Good fit for
Chat-only assistant (no connectors)	Draft and summarize text users paste in	Staff pasting confidential data into an unapproved tool	Approved-tool list, acceptable-use policy, enterprise data terms	Drafting, research, brainstorming
Embedded copilot (e.g. inside Microsoft 365)	Read everything the user can read; draft, not send	Oversharing via stale permissions	Permissions cleanup, sensitivity labels, audit logging	Search, meeting recaps, first drafts
Connected agent, read-only	Pull data from several systems and report	Prompt injection leading to data exposure	Scoped service identity, connector allow-list, output review	Intake triage, reporting, research across systems
Connected agent with write access	Send, file, update records, trigger workflows	Unauthorized or irreversible actions at machine speed	Human approval on consequential actions, least privilege, full action logs, kill switch	Narrow, well-defined, repeatable workflows
Fully autonomous agent	Chain actions with no human in the loop	All of the above, compounding	Everything above, plus sandboxing and ongoing monitoring	Rarely appropriate for SMBs today

A useful rule: the more irreversible and external an action is (sending to a client, moving money, deleting records), the more you want a person clicking approve. Reading and drafting can be automated aggressively. Sending and deleting should almost always be gated.

The Readiness Checklist: Do These Before Connecting Anything

These are the controls we see missing most often when a business wants to turn on agents. Each is achievable with tools most Microsoft 365 tenants already have.

Identity and access

• Enforce phishing-resistant MFA for every account that will use or administer agents. An agent is only as trustworthy as the identity it runs as.
• Give agents their own identities or service accounts rather than letting them run under a partner’s or administrator’s credentials, so actions are attributable and revocable.
• Restrict who can grant OAuth consent to third-party apps. In Microsoft Entra, require admin approval for new app consents so staff cannot connect an agent to the whole tenant on their own.
• Review existing enterprise app grants and remove anything unused or unrecognized.

Data exposure

• Run an oversharing review of SharePoint, OneDrive, and Teams before enabling an embedded copilot. Remove ‘Anyone’ and organization-wide links on sensitive content.
• Apply sensitivity labels to client files, HR records, and financials, and use them to exclude the most sensitive content from AI processing where your tools allow it.
• Decide which repositories agents may never touch, such as privileged matter files or personnel records, and enforce that with permissions rather than instructions.

Actions and oversight

• Scope each agent to the minimum tools needed. A summarization agent needs read, not send or delete.
• Require human approval for sending external email, changing financial data, deleting content, and changing permissions.
• Confirm you can turn an agent off instantly and revoke its tokens without breaking other systems.

Logging

• Turn on and retain unified audit logging, and confirm agent actions appear with enough detail to reconstruct what happened.
• Route those logs to whoever monitors your security alerts, so an agent mass-downloading files triggers the same response as a compromised user would.

Governance That Fits a Small or Mid-Sized Firm

You do not need an AI ethics committee. You need a named owner, a short written policy, and a repeatable review. The NIST AI Risk Management Framework organizes this into four functions (Govern, Map, Measure, Manage), and NIST’s Generative AI Profile (NIST AI 600-1) adds generative-AI-specific risks such as information security and data privacy. Scaled down, that looks like this:

• Govern: Name one accountable owner for AI tools. Publish an approved-tool list and a one-page acceptable-use policy covering what data may and may not go into AI systems.
• Map: Keep an inventory of every agent and connector: what it does, what identity it uses, what systems it touches, and who approved it.
• Measure: Test each agent before rollout, including deliberately feeding it a document with hidden instructions to see what it does.
• Manage: Review the inventory on a set schedule, revoke unused access, and re-test after vendor updates, since agent behavior can change when the underlying model changes.

Federal guidance points the same way. CISA, the NSA, and FBI’s joint AI Data Security guidance emphasizes protecting the data AI systems use across their lifecycle, including access control, data provenance, and monitoring.

California and Professional-Services Obligations

For Los Angeles firms, agent decisions also carry legal and ethical weight.

California privacy rules. The California Privacy Protection Agency has finalized regulations covering automated decision-making technology, risk assessments, and cybersecurity audits, with obligations phasing in over the next several years. Check the CPPA regulations page for the dates that apply to your business. If an agent helps make significant decisions about consumers or employees, such as screening applicants, assume it falls within scope and document how it works.

Lawyers’ duties. The State Bar of California’s Practical Guidance for the Use of Generative AI says lawyers must not input confidential client information into any AI solution that lacks adequate confidentiality and security protections, and must supervise AI output. The ABA’s Formal Opinion 512 similarly addresses competence, confidentiality, client communication, and supervision when using generative AI. An agent with inbox access at an entertainment-law firm is reading privileged deal terms and talent contracts. That calls for the write-access controls in the table above, even for a read-only tool.

Insurance. Carriers increasingly ask how you manage access and monitor for anomalous activity. An undocumented agent with broad permissions is exactly the kind of gap that complicates a claim. Tell your broker what you are deploying.

A Phased Rollout That Avoids the Common Mistakes

Phase 1: Contain and inventory. Find out what AI tools staff already use. Shadow AI is almost always present. Publish the approved list, lock down OAuth consent, and turn on audit logging.

Phase 2: Clean up and enable low-risk tools. Fix oversharing, apply sensitivity labels, and roll out chat and embedded copilot tools that read and draft but do not send.

Phase 3: Pilot one connected workflow. Choose a narrow, high-volume, low-consequence process, such as intake triage, meeting-to-task extraction, or document indexing. Run it read-only first, then add write actions behind human approval. Measure time saved and error rate.

Phase 4: Expand deliberately. Add workflows one at a time, each with its own scoped identity, inventory entry, and test. Do not grant broad autonomy just because the pilot went well.

The biggest mistake we see is skipping to Phase 3 with a tool a single employee connected to their own account. The second biggest is Phase 2 without permissions cleanup, which turns a copilot into an internal search engine for salaries and client files.

Questions to Ask Any AI Vendor or IT Provider

• What identity does the agent run as, and can we scope it to specific sites, mailboxes, or records?
• Which actions can it take without a human approving them, and can we require approval per action type?
• Is our data used to train models, and where is it processed and retained?
• Are agent actions logged in our own audit trail, with enough detail to investigate an incident?
• How do we revoke access instantly, and what happens to in-flight tasks?
• How does the product defend against prompt injection, and what does it do when it encounters suspicious instructions?
• Who is responsible for monitoring the agent after go-live?

If a vendor cannot answer these clearly, the product may still be useful, but only at the chat-only or read-only level.

We Solve Problems helps enterprise leaders and their teams put AI to work through a three-year enablement roadmap. Your team owns the decisions and builds the capability; we provide hands-on teaching and ongoing guidance. See the AI enablement roadmap.