AI Agents With Real-World Access: A Governance Playbook for LA Businesses
The Decision In Front Of You
Until recently, the AI question for a business owner was whether to let staff paste company information into a chatbot. That question is settled in practice — McKinsey’s State of AI research found 88% of organizations report regular AI use in at least one business function, and the number inside your company is almost certainly higher than what IT has approved.
The live question now is different and much sharper: do you let an AI agent take actions inside your systems? Not summarize the inbox — send from it. Not describe the invoice — post it to the ledger. Not read the matter file — move it, share it, or email it to opposing counsel.
That is a security and liability decision, not a productivity decision, and it cannot be answered with a blanket yes or no. The right answer is per-system and per-action. This post lays out how to make that call, what has to be in place before an agent touches anything that matters, and what California regulators now expect you to document.
What Actually Changed: Agents Got Hands
A chatbot produces text. An agent produces effects. Three shifts in the last eighteen months made this real for ordinary businesses, not just engineering teams:
Tool-calling became standard. Assistants can now invoke external tools mid-task — search, file operations, API calls — rather than only returning words.
Connectors got a common plug. The Model Context Protocol gave AI products a standard way to attach to CRMs, file stores, ticketing systems, and databases. A non-technical employee can now connect an assistant to a live business system in minutes, often without an admin approving it.
Browser and desktop agents arrived. Agents that drive a browser session inherit whatever that session is logged into. If the user is authenticated to your bank portal, payroll, or practice-management system, so is the agent.
The security consequence is blunt: your existing controls were designed around a human making a decision before an action occurs. Agents remove the human from the middle of the loop, and most of the damage models in your security stack assume that human is still there.
The Four Ways Agent Deployments Fail
Across deployments, failures cluster into four patterns. Each has a specific control that addresses it.
1. Prompt injection. Instructions hidden in content the agent reads — a web page, a PDF, an email signature, a shared document — get treated as commands. The OWASP Top 10 for LLM Applications ranks prompt injection as LLM01, the number-one risk, and OWASP’s companion guide on agentic AI threats and mitigations extends it to agent-specific variants like tool misuse and memory poisoning. There is no reliable filter that catches all of it. The control is not detection — it is limiting what the agent can do when it is fooled.
2. Over-permissioned identity. The fastest way to deploy an agent is to give it a user’s credentials or a shared admin account. That single shortcut is how a mistake in one workflow becomes access to everything that user could reach. IBM’s Cost of a Data Breach report found that 13% of organizations reported breaches involving AI models or applications, and 97% of those lacked proper AI access controls — access, not model security, is the failure point.
3. Silent data egress. An agent summarizing a folder may transmit the contents to a third-party model provider under terms nobody in your business has read. For a law firm holding client confidences or a production company under a studio NDA, that is a contractual breach whether or not anything leaks publicly.
4. No audit trail. When something goes wrong, you need to answer: which agent, acting for whom, under what instruction, touched what record, and when. If the agent acted as a human user, your logs say a human did it. You will not be able to prove otherwise to a client, an insurer, or a regulator.
Four Postures: Pick One Per System, Not One For The Company
The useful mental model is a posture assigned to each system, based on what an agent could do there on its worst day. Most businesses should be running all four at once across different systems.
| Posture | What the agent can do | Blast radius if compromised | Controls required first | Good fit for |
|---|---|---|---|---|
| Blocked | No access; the system is on a deny list enforced at the network and identity layer | None | Conditional access policy, approved-app list, blocked unsanctioned AI domains | Payroll, banking and wire initiation, cap tables, escrow, PHI systems, studio-restricted content stores |
| Read-only, sandboxed | Reads a defined data set, returns text to a human; cannot write, send, or share | Disclosure of what it could read | Scoped data set, sensitivity labels applied, data-retention terms confirmed with the vendor | Research, first-draft summaries, knowledge-base Q&A, contract review where the corpus is already internal |
| Scoped write, human approval | Drafts and stages real actions — replies, tickets, ledger entries — but a named human approves before execution | Wasted time; near-zero data or financial loss | Dedicated agent identity, approval step enforced in the tool (not by policy), full action logging | Help desk triage, AP coding, intake, CRM hygiene, scheduling, document assembly |
| Autonomous write | Executes without per-action human review inside a fixed boundary | Everything inside the boundary, at machine speed | Everything above, plus rate limits, transaction caps, an automated kill switch, and monitoring with alerting | High-volume, low-stakes, reversible tasks: file routing, tagging, internal notifications, data normalization |
The common mistake is jumping to autonomous write because a demo looked good. The disciplined move is to run a workflow at scoped write with human approval long enough to measure how often the human actually corrects the agent. If corrections are rare and the failure cost is low and reversible, you have earned the right to consider autonomy. If you never measured, you have not.
Give Every Agent Its Own Identity
This is the single highest-leverage control, and it is the one most businesses skip. An agent is a non-human identity and should be provisioned like one.
| Identity model | Attribution in logs | Revocation | Permission scope | Verdict |
|---|---|---|---|---|
| Runs as an employee’s account | Indistinguishable from the human | Breaks the employee’s own access | Everything that employee can reach | Avoid |
| Shared service account | Attributable to “the service,” not the workflow | All-or-nothing across every workflow using it | Accumulates permissions over time | Avoid |
| Dedicated identity per agent or workflow | Precise: which agent, which action, which record | Disable one agent without touching anyone else | Least privilege, scoped to the specific task | Correct model |
In a Microsoft 365 environment — where most of our clients live — this means workload identities with scoped permissions rather than borrowed user accounts, conditional access applied to those identities, and sensitivity labels doing real work. Microsoft’s documentation on Copilot data handling is explicit that the assistant respects existing permissions, which is exactly why oversharing is the hidden problem: if a SharePoint site is open to “everyone in the organization,” an agent will surface it faithfully and instantly. Fix permissions before deploying an agent, not after. The agent does not create the oversharing problem — it makes it searchable.
Also worth internalizing: NIST SP 800-207, the Zero Trust Architecture standard, already describes the right model here. Every request is authenticated, authorized, and evaluated against policy regardless of origin. An agent is just another subject. If you have done zero trust work, you are most of the way to agent governance.
The Pre-Flight Checklist
Before any agent gets access to a production system, these should be true and written down:
- The data it can reach is enumerated. Not “the SharePoint” — the specific sites, libraries, and mailboxes. If you cannot enumerate it, the answer is not yet.
- Permissions were audited within the last quarter. Stale group membership is the most common source of accidental agent access.
- The agent has its own identity with least-privilege scopes, and the credentials are not in a spreadsheet.
- Every action is logged to a system the agent cannot modify, with retention that matches your regulatory and insurance obligations.
- A named human owns the workflow. Not a department. A person who is accountable for its output and who can turn it off.
- The kill switch has been tested. Someone actually disabled the agent mid-task and confirmed it stopped.
- Vendor data terms are confirmed in writing — training use, retention period, subprocessors, and geography.
- The action is reversible, or it is gated. Irreversible actions (wires, external sends, deletions, filings) always require human approval, regardless of how well the agent performs.
- Your cyber insurer knows. Carriers are adding AI-related questions to applications and renewals; a material misstatement is a coverage problem later.
CISA and its international partners published joint guidance on deploying AI systems securely that covers the environment-hardening side of this in more depth, and the NIST AI Risk Management Framework organizes the whole program into four functions — Govern, Map, Measure, and Manage — which is a defensible structure to point an auditor or client at.
Why The Threat Math Favors Discipline
Two numbers should shape how conservative you are about autonomous write access to anything financial.
The FBI’s 2024 Internet Crime Report recorded $16.6 billion in reported losses, with business email compromise alone accounting for $2.77 billion. BEC works by making a fraudulent instruction look routine. An agent with send authority over a mailbox is, from an attacker’s perspective, a BEC engine that never gets suspicious.
The Verizon Data Breach Investigations Report found the human element involved in roughly 60% of breaches, and third-party involvement doubled to 30%. Agents sit at the intersection of both: they execute human intent and they are usually a third-party product with access to your data. IBM’s research puts the global average cost of a breach at $4.44 million, with the United States highest at $10.22 million — and that is before you add the client-notification and malpractice exposure a professional services firm carries.
None of this argues against using agents. It argues for putting irreversible actions behind a human and everything else behind a scoped identity with logs.
What California Law Now Expects
California businesses have a compliance clock running that most owners have not looked at.
The California Privacy Protection Agency finalized regulations covering automated decisionmaking technology, cybersecurity audits, and risk assessments in 2025. The parts that matter for agent deployments:
Automated decisionmaking technology. If you use ADMT to make a significant decision about a consumer or an employee — hiring, promotion, termination, allocation of work, financial services, housing — you owe pre-use notice, an opt-out in most cases, and an explanation on request. Businesses must be in compliance with these requirements by January 1, 2027. An AI agent screening applicants or scoring customers is squarely in scope, and “we bought it from a vendor” is not a defense.
Risk assessments. Processing activities that present significant risk to privacy — including certain ADMT uses and training of automated systems — require documented risk assessments, with the first submissions to the agency due in 2028. The practical implication is that the documentation you create now, as you deploy, is the record you will file later. Retroactive assessments are painful and less credible.
Cybersecurity audits. Larger businesses face phased annual audit obligations beginning in 2028. If you are on that path, the controls described in this post are the same controls an auditor will test.
Separately, the California Attorney General continues to enforce the CCPA directly, and service-provider contract terms — the ones that govern what your AI vendor may do with data you send — are a recurring theme in enforcement. Read the data processing addendum before you connect the agent, not after.
Entertainment, Legal, And The Studio Security Questionnaire
In Los Angeles this is not abstract. Two local realities change the calculus:
Content security obligations. Vendors touching pre-release content are routinely assessed against MPA-aligned controls through the Trusted Partner Network. Those assessments ask where content lives, who can access it, and how access is logged. An AI agent with read access to a project folder is a new access path that your last assessment did not contemplate. If you are TPN-assessed or working for a studio that requires it, treat agent access to content stores as blocked until it is explicitly reviewed and documented.
Professional confidentiality. For entertainment law firms and the professional services firms around them, client confidences are governed by ethical duties, not just privacy statutes. Outside counsel guidelines increasingly restrict where client data may be processed and prohibit its use for model training. Before connecting an agent to a document management system, map which clients’ guidelines cover that data. In practice, the answer is often that agents are fine for firm-internal work — intake, billing narratives, knowledge management, conflicts research — and restricted for client matter files until specific consent or contractual clearance exists.
Entity sprawl. Single-purpose production entities, loan-outs, and co-production JVs mean the LA businesses we work with often run multiple tenants, multiple sets of credentials, and file shares that outlive the project. Agents inherit that mess. Cleaning up tenant and permission sprawl is usually the first real project, and it pays for itself independent of any AI work.
A Staged Rollout That Does Not Stall The Business
The governance posture above can be adopted without freezing everything. A sequence that works:
First, inventory and contain. Find out what is already connected. Check OAuth grants and third-party app consents in your Microsoft 365 or Google Workspace tenant — this is usually the moment a business discovers an employee connected an AI tool to the entire file store six months ago. Disable unsanctioned connectors and turn off end-user app consent so new ones require admin approval.
Second, fix permissions. Run an oversharing report. Remove “everyone” and “anyone with the link” sharing on anything sensitive. Apply sensitivity labels to the categories that matter most: client matters, contracts, financials, unreleased content, personnel files.
Third, publish a one-page policy. Approved tools, what data may go into each, which systems are blocked outright, and who to ask. One page that people read beats a twelve-page policy that nobody opens. The FTC’s small business cybersecurity guidance is a reasonable baseline to build the rest of your written program around.
Fourth, pilot one workflow properly. Pick a high-volume, reversible, annoying task — AP coding, help desk triage, intake summarization. Give the agent its own identity, run it at scoped write with human approval, and log everything. Measure correction rate and time saved.
Fifth, expand on evidence. Promote workflows to more autonomy only where the measured correction rate justifies it, and only for reversible actions. Re-run the permission audit each quarter, because permissions drift and agents amplify drift.
How To Tell If Your IT Provider Is Ready
Ask your current provider four questions. The answers are diagnostic.
- “Show me every third-party app and OAuth grant with access to our tenant right now.” If this takes them more than a day, nobody is watching that surface.
- “Which of our SharePoint sites or shared drives are overshared internally?” If the answer is a shrug, an AI assistant will find them before your IT provider does.
- “How would we prove an AI agent, not an employee, performed a given action?” If agents run on human accounts, the honest answer is that you cannot.
- “What is our documented position for the CPPA ADMT requirements taking effect January 1, 2027?” If there is no answer, the compliance clock is running unattended.
A provider whose only AI story is “we resell a chatbot” is not equipped for this. The work is identity design, permission hygiene, logging, vendor contract review, and workflow measurement — which is ordinary managed IT discipline applied to a new class of actor.
We Solve Problems runs both sides of this for our clients: the managed IT foundation — Microsoft 365 security, identity, and compliance — and the AI operations work of finding the manual workflows worth automating and deploying agents that are scoped, logged, and accountable. We are based in Los Angeles with particular depth in entertainment law and professional services, and we work with clients across the US. If you are weighing where AI agents should and should not touch your business, request a consultation and we will start with what is already connected to your tenant.