An AI chief of staff with the keys to your stack is a different beast from one that only answers questions. The moment it can read your inbox, pull from the CRM, open a pull request or move money, the risk model changes. Convenience and exposure now sit on the same ledger. The question is not whether to grant access, but what the controls must do before you do.
The industry data has caught up with the intuition. Cloud Security Alliance research found that 65% of organizations experienced at least one cybersecurity incident related to the use of AI agents in the past year, with data exposure (61%), operational disruption (43%), and unintended actions in business processes (41%) as the most common consequences. IBM's 2025 Cost of a Data Breach Report puts the problem in sharper terms: 97% of organizations that reported an AI-related breach lacked proper AI access controls, and 63% of breached organizations had not established policies for AI governance or preventing shadow AI. Access controls are not a nice-to-have around an AI chief of staff. They are the product.
What follows is the surface you should expect any AI agent to defend, and the checks to run before you give it a token.
Start With Scope, Not Role
A chief of staff that connects to Gmail, Calendar, Drive, the CRM, GitHub, the CMS, Search Console, Analytics, Google Ads and Stripe inherits each system's own notion of permission. Those notions are not aligned. "Sales" in your CRM is not the same thing as "Sales" in your ad account, and both are coarser than what an agent should carry.
The right default is per-person scope that mirrors what that person already sees. If a sales lead cannot view finance reports in their day job, the agent acting for them should not either. This is the shape of the principle long written into government controls: NIST SP 800-53 control AC-6 requires organizations to employ the principle of least privilege, allowing only authorized access necessary for users or processes acting on their behalf to accomplish assigned tasks. The same page states it; your agent should enforce it.
Role-based access alone will miss this. Roles are blunt. What you want is scope that binds to the identity on whose behalf the agent is acting, inherited from the source system where possible, and reviewed on connection rather than once a quarter. The brigham.ai Integrations page documents which systems the agent connects to and the posture it takes with each.
Per-Person Inbox Isolation Is Non-Negotiable
Email is the sharpest edge of per-person data access. An inbox contains salary negotiations, legal correspondence, a quiet reference check, a founder's note to a board member. If an admin can read it, or if another person's agent can read it, you have not given someone an AI assistant. You have given the company a surveillance tool.
The rule to require: each person's inbox is private to them, administrators included. The agent that drafts a reply for you reads your mail and no one else's. An admin that provisions access does not thereby acquire the ability to view it. This is a product property, not a policy promise, which means it has to be enforced by the authentication path and auditable in the logs. If the vendor cannot show you where in the code that isolation lives, assume it does not.
Policy-Checked Tool Calls, In Code
Every call an agent makes to a connected system is a tool call: read a thread, create a draft, move a stage, open a pull request, send money. The question is where the rules about those calls live. If they live only in the system prompt, they do not exist. The OWASP Top 10 for LLM Applications 2025 identifies Excessive Agency (LLM06), rooted in excessive functionality, excessive permissions, and excessive autonomy, as a top risk, highlighting the danger of agents acting with broader privileges than needed and executing high-impact actions without a human in the loop.
What policy-in-code means in practice:
- Reads are allowed within the person's scope and logged.
- Reversible writes (a draft, a calendar hold, an internal note) run under policy and are reversible by the same path.
- Sensitive actions (sending email, publishing, deploys, ad budgets, money movement, deletes) always wait for a person, and the approval is bound to the exact payload the agent will send. The approvals piece on this site, why AI agent approvals must be bound to the exact action, works through the mechanics.
The point of in-code policy is that it is checked on every call, not inferred from an instruction the model is asked to remember. A model that forgets its instructions is a known failure mode. A policy function that refuses the call is not.
Finance Is Its Own Protected Domain
Treat finance as a separate world, not a sub-scope of the CRM. Stripe read-only, bank balances, invoice drafts, ad budget changes, payroll views — these should be gated per person, granted explicitly, revocable, and never implied by a job title. "Head of Operations" does not automatically mean "can see revenue by customer." It means someone decided they could, and the system recorded that decision.
The practical implication is granularity. A person might have scope to view aggregate ad spend without seeing per-campaign CPA by customer. They might approve a vendor payment up to a cap and not above it. The agent inherits those limits and refuses anything outside them, with the refusal logged. If finance is a mode a role unlocks rather than a protected domain granted per person, the surface is too wide.
Source-Dated Memory
An AI chief of staff is only useful if it remembers what it has learned about your business. Memory is also where hidden data leakage lives. A memo written six months ago, stored as "fact," surfaces in a briefing today and influences a decision that the current reality no longer supports. Worse, a confidential note from one deal appears in a reply about another.
Three properties keep memory honest:
- Source attached. Every remembered fact points to the document, thread or system call that produced it.
- Last-verified date. Memory ages. A pricing claim from Q1 is marked as such and treated with the appropriate skepticism in Q4.
- Scope on recall, not just capture. A fact learned from a document only the finance lead can see is not retrievable by someone whose scope does not include that document, even if the agent "knows" it.
If memory is a flat store with no provenance, it will eventually say something true about the wrong person to the wrong person.
Audit And Cost Logs You Can Actually Read
A good audit trail answers three questions quickly: who asked, what was called, and what changed. For an AI agent that means every tool call, with the identity it acted on behalf of, the policy decision, the payload, and the outcome. Cost belongs on the same line: a model call that read 40,000 tokens of a Drive folder should show up as both a read event and a dollar figure.
The reason to design logs this way is operational, not performative. SOC 2 Type II audits require continuous evidence that controls operated effectively over the audit period, typically six to twelve months, meaning audit logs must be generated continuously and retained throughout the period, not captured on demand. If you ever need to answer "what did the agent do on behalf of this person between March and September," you will want that trail already written. The Trust page lays out how brigham.ai treats this surface.
Containment matters as much as logging. IBM's 2025 Cost of a Data Breach Report found organizations identified and contained breaches in a mean time of 241 days — the lowest in nine years. The number is still eight months. An audit trail that lets you reconstruct an agent's behavior in minutes rather than months is the difference between a contained incident and a disclosure.
MCP Servers And Third-Party Tools: Review Before Install
The MCP ecosystem is the newest surface and the one most likely to go unchecked. An MCP server is a tool the agent can call. Each one is code written by someone, exposing some set of actions, with its own authentication path. Install one without review and you have widened the scope of your agent to whatever that server can do, including things the server author did not advertise.
Before you connect any third-party server, the checks are small and worth doing:
- Who publishes it, and is the source readable.
- What scopes it requests and what actions it exposes.
- Whether its calls are subject to the same policy-in-code checks as native integrations.
- Whether sensitive actions it offers route through the same approval flow.
- Whether it logs to the same audit trail, with the same identity attribution.
If any of those answers is "no" or "unclear," the server is a shadow IT installation with model autonomy attached. Decide against it until the answers are clear.
Human-In-The-Loop For Decisions With Consequence
Some actions are not just sensitive but regulated. GDPR Article 22 gives data subjects the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects, and requires at minimum the right to obtain human intervention, express a point of view, and contest the decision. If your agent is involved in hiring screens, credit decisions, pricing offers or anything that affects a customer's standing, "a person approved this" is not optional.
In practice, this means the approval UI shows the exact payload — the message, the mutation, the amount — and the approval binds to that payload. Any edit forces a new approval. This is the piece that the top functions of an AI chief of staff, with numbers post treats as a feature; here it is the regulatory floor as well.
A Checklist Before You Grant Access
Run this before any AI agent reads or writes to your stack. If you cannot get a clear answer to each item, the surface is too wide:
- Scopes are per person and inherited from the source system where possible.
- Inboxes are private to the person, administrators included.
- Every tool call is checked by policy in code and classified as read, reversible write, or sensitive.
- Sensitive actions wait for a person, with approval bound to the exact payload.
- Finance is a protected domain granted per person, never implied by role.
- Memory carries a source and a last-verified date; recall is scoped.
- Audit and cost logs are continuous and queryable by person, system and payload.
- Third-party MCP servers go through the same policy, approval and audit paths before install.
Where To Go From Here
If you are evaluating an AI chief of staff, the checklist above is the shortlist to put in front of a vendor. The right answers should be specific and demonstrable, not aspirational. Start a conversation on the early access page and ask for the policy code paths, not the marketing deck.
If you already run an agent and the controls are not visible, treat it as an audit project this quarter. Pull the logs, map the scopes, list the installed tools and MCP servers, and identify every sensitive action that is not currently gated on a human. Close the easy weak points first (inbox isolation, finance scoping, approval binding) before you add any new capability.
If you are a security lead inside a team that already wants to move faster with AI, your advantage is to make the safe path the easy one. Write the policy in code, make the audit queryable, and show the operators that approvals bound to payload are faster to reason about than freeform agent autonomy. The alternative shows up in the breach statistics.
