Ksenia Kartamysheva - Governance comes down to four decisions: what an agent can see, what it can change, who approves, and how its actions are recorded.
- The agent should inherit the signed-in user’s role, never a shared account with wider access.
- Start read-only, then allow operational writes with previews, and keep financial records for last.
- Set approval by record type: reads and drafts need none, operational changes need previews, and financial records need a named approver.
- Logs should show which changes came through an assistant, and data residency covers both the PSA and the assistant provider.
Governing AI agents in a PSA means deciding what an agent can see, what it can change, who must approve, and how every action is recorded. Start with the agent acting only as the signed-in user, begin read-only, require human approval for bulk and financial changes, keep an action log you can review, and confirm where your data goes when an outside assistant reads it.
Most operations and finance leaders will approve an AI assistant that drafts a status report. They hesitate when the same assistant can move a deadline across 40 tasks or touch a time entry that ends up on a client invoice. On the assist, recommend, act scale, that is the move from recommend to act.
Vendors know this. When Klient launched MCP servers for its Salesforce PSA on June 17, 2026, the announcement led with the AI working under the user’s own permissions, with every action auditable. The controls still sit with the customer, because the assistant, its settings, and the approval policy are yours.
The gaps predate AI. In about 30% of Birdview discovery calls between March 2025 and March 2026, prospects had no approval workflows at all. An agent inherits that gap and runs it faster.
What can go wrong when an AI agent touches PSA records?
Five things go wrong in practice: a bad bulk change, a recommendation acted on without review, an error in a financial record, data exposure, and no record of who made a change. Each has a different fix, so a single “AI on or off” switch is not a policy.
A bad bulk change is the most common. A PM asks to “push the design phase back a week,” the assistant reads “design” too broadly, and 120 tasks across three projects move. Resource plans and client dates stay wrong until someone notices.
A recommendation acted on without review is quieter: an assistant proposes a consultant whose calendar looks free but who is verbally committed to another client. Financial record errors cost the most, because a wrong time entry or rate flows into WIP and invoices and becomes revenue leakage.
Data exposure happens when broad access lets an assistant summarize margins for someone who should not see them. Missing attribution turns every other failure into a longer investigation.
The OWASP Top 10 for LLM Applications calls the root cause “excessive agency”: too much functionality, permission, or autonomy. The five controls below address all three.
The five controls that govern an AI agent in PSA software
AI agent governance in a PSA comes down to five controls: role-based access, read versus write limits, human approval, logging, and data residency. Each answers a question finance or the PMO will ask before signing off.
1. Role-based access: the agent never sees more than the user
An AI agent should act as the signed-in user and inherit that user’s role, never a shared account with wider access. Each person authorizes it with their own login, role changes flow through automatically, and offboarding cuts off the assistant at once.
In Birdview, the MCP connector signs in through OAuth as the user, so it sees and edits only what that role allows. On corporate ChatGPT or Claude accounts, an admin adds the connector once and each person authorizes it with their own Birdview login. Because the assistant inherits the role, review job roles and access levels first: an over-permissioned role becomes an over-permissioned assistant. Teams that already separate full and restricted PSA licenses start ahead.
2. Read versus write actions: start read-only
Begin read-only, then allow low-risk writes once the team trusts the output. Reading status and workload carries little risk; writing to plans, assignments, or financial records is where governance matters. Keep time entries, expenses, rates, and budgets out of write scope until their approval chain is proven.
Birdview’s connector reads project status, portfolios, tasks, workload, and time off, and writes tasks and projects, including bulk changes. Expenses and payments are read-only, and in the current beta it cannot log time or submit or edit time entries and expenses. Claude users can restrict the connector to read-only; because that setting lives in the AI client, make it policy rather than personal preference.
3. Human approval steps: preview, threshold, named approver
Any change that touches many records, or any financial record, needs a human look before it lands. A preview shows what will change, a threshold forces a pause on large changes, and a named approver keeps financial accountability with a person.
In Birdview, bulk changes can be previewed first, and any change affecting more than 50 tasks requires an extra confirmation. For time and expenses, keep your existing chain, such as multi-step time log approvals and expense approval, in front of anything an assistant drafts.
4. Logging and audit trails: who, what, when, and through which assistant
Every agent change should record the user, the action, the target record, and the time, and be distinguishable from a manual change. Otherwise the log shows that Maria changed 50 tasks, not that her assistant did. Check retention too: a 90-day window does not help when a client disputes an invoice from two quarters ago.
Birdview lists user audit logs among its platform security features. With any vendor, ask whether assistant-initiated changes are labeled as such.
5. Data residency and data flow: know both locations
AI data residency has two parts: where the PSA stores data, and where data goes when an assistant reads it. A PSA hosted in Canada does not keep data in Canada once another provider’s assistant pulls it into a chat. In about 35% of Birdview discovery calls, prospects named a residency requirement.
Birdview hosts data in the USA, Canada, or Europe. Through MCP, data goes only to Birdview and the assistant the user chose, whose provider terms then apply. The ownership, residency, and hosting checklist works for both sides.
How should approval levels change by PSA record type?
Set the approval level by the consequence of the record, not by the AI feature that touches it. A wrong status summary costs minutes; a wrong billing rate costs a client conversation.
| Tier | PSA records | What the agent may do | Human step required |
| 1. Read and draft | Status reports, portfolio summaries, workload views, draft plans and messages | Read freely within the user’s role; produce drafts | None beyond the user reading the output before sharing it |
| 2. Operational changes | Task status, dates, estimates, assignments, project setup | Write within the user’s role | Preview for bulk changes; extra confirmation above a set threshold (Birdview’s is 50 tasks) |
| 3. Financial and client-facing | Time entries, expenses, billing rates, budgets, invoices, revenue recognition | Read, or draft for review only | A named person approves; the same person or assistant cannot both enter and approve |
The Tier 3 rule is segregation of duties: an assistant acting for a user must never submit a time entry and approve it under the same authority. A well-run timesheet approval workflow already separates entry from approval; keep the assistant on the entry side.
Tier 2 also covers scope. Tasks an assistant adds to a fixed-fee project should go through the same change and scope control approvals as a manual change. Accountability stays with the person who authorized the assistant, and your policy should say so.
The AI agent governance checklist for PSA buyers
Use this checklist to compare vendors and to set your own policy. The Birdview column lists only what Birdview documents publicly today.
| Control | What good looks like | Question to ask any PSA vendor | Birdview (documented today) |
| Role-based access | Agent acts as the signed-in user; offboarding removes access immediately | Does the assistant use each user’s own login and role, or a shared account? | OAuth sign-in as the user; sees and edits only what the role allows; SSO, SAML, and 2FA on every plan |
| Read versus write | Read-only pilot first; financial records outside write scope | Can an admin limit the assistant to read-only, per user or per role? | Reads and writes tasks and projects; expenses read-only; no time logging or expense submission in the beta; read-only restriction available in Claude |
| Human approval | Preview for bulk changes, threshold confirmation, named approver for financials | What confirmation applies to bulk or financial changes, and can we set the threshold? | Bulk preview; extra confirmation above 50 tasks; time log and expense approval workflows in the PSA |
| Logging | Who, what, when, target record, and assistant-initiated flag; exportable; retained for your audit period | Are assistant changes labeled in the audit log, and how long are logs kept? | User audit logs listed among platform security features |
| Data residency | Known storage region for the PSA and known handling by the assistant provider | Where is data stored, and where does it go when an assistant reads it? | Hosting in the USA, Canada, or Europe; MCP sends data only to Birdview and the chosen assistant |
| Independent assurance | Current SOC 2 Type II report with a clear system scope | Which products and features does your SOC 2 report cover? | SOC 2 Type II audit completed in 2026 |
If a vendor answers “we’re working on it” on logging, plan a manual review step until that row is filled. The checklist is also available as an ungated one-page download for your security review.
A 30-day rollout for AI agents in your PSA
Roll out an AI agent in four one-week steps: read-only pilot, operational writes with previews, a log review, then a written policy.
- Week 1: read-only pilot. Connect 3 to 5 users (a PM, a resource manager, someone from finance) with one named owner across operations, finance, and IT.
- Week 2: Tier 2 writes. Allow task and project updates, with a preview on every bulk change.
- Week 3: review logs. Count how many assistant changes a person had to reverse. Above 1 in 10, stay at week 2 and fix prompts or roles.
- Week 4: write the policy. One page covering who may connect an assistant, which tiers are allowed, and who reviews logs, how often. Then decide on expansion.
The 1-in-10 figure is a starting point, not a benchmark: an agency shifting task dates can tolerate more corrections than an engineering firm whose dates drive subcontractor bookings. Revisit the policy quarterly and after any connector change, because MCP connectors, Birdview’s included, are adding actions quickly.
What SOC 2 and data residency do and do not cover
SOC 2 Type II is an independent audit of a vendor’s security controls over time, and data residency says where data is stored. Neither certifies what your assistant does or whether its recommendations are right.
Birdview’s 2026 SOC 2 Type II audit is vendor-side assurance about the platform the assistant connects to, not about the assistant, its provider, or your team’s decisions. With any vendor, check the report’s system description to see which products are in scope.
Residency has the same limit: a PSA can store data in a Canadian data center while an external assistant processes it elsewhere. Birdview’s explainer on what “sovereign” means when a vendor says it separates storage location from where the model runs; apply that split to every AI flow in your PSA.
Making AI agents safe to switch on
Governing AI agents in a PSA is an operating decision: settle access, actions, approvals, evidence, and data location, tier approvals by record type, and start read-only.
Evaluating Birdview? Download the checklist, bring your approval policy to a demo, and ask for a walkthrough of the permission model behind the Birdview MCP connector and the AI assistant using your own roles.
FAQ
What permissions does an AI agent get in PSA software?
A well-governed agent gets exactly the permissions of the person who connected it, through that person’s own login, so it cannot see projects, rates, or margins they cannot see. Birdview’s MCP connector signs in through OAuth as the user. Tighten roles before connecting an assistant, because any excess access carries over.
Should AI agents be allowed to edit time entries or invoices?
For most professional services firms, not without a human approver. Time entries, expenses, rates, and invoices feed billing and revenue recognition, so errors reach the client. Let the assistant draft or flag these records, have a named person approve them, and keep entry and approval as separate steps no single assistant can complete.
How do you audit what an AI agent changed in a PSA?
Confirm the audit log records the user, action, record, and time, plus a marker showing the change came through an assistant. Logs should be exportable and kept for your full audit period. Until assistant changes are clearly labeled, review bulk changes made by pilot users every week.
Does SOC 2 cover AI agents?
No. SOC 2 Type II covers a vendor’s own security controls over an audit period, within the scope described in the report. It does not certify your AI assistant’s behavior, the assistant provider’s data handling, or the accuracy of AI recommendations. Ask which products the report covers, and govern the assistant separately.
