Atlassian recently deployed an 'Agentic Multiplayer Protocol' that requires every AI agent in their ecosystem to display a visible profile with a named human owner. Mike Cannon-Brookes was blunt about where accountability must sit: 'It has to be with the end user, ultimately.' At the same time, Microsoft flagged AI agents as insider threats requiring zero-trust controls, noting that frontier models can't be trusted with unrestricted access.
For accounting firms testing automation—payment reminders, document requests, invoice follow-ups—this dual signal is clarifying: the moment an agent acts on behalf of your practice, someone must own what it does. That constraint isn't overhead. It's the permission structure that lets you scale repetitive comms without losing client trust.
What changed: human attribution as a technical requirement
Atlassian's control plane doesn't just log which agent sent a message—it surfaces the human owner in the interface. When an AI assistant pings a colleague about a missing approval or chases an overdue invoice, the recipient sees 'Sarah Chen's assistant,' not a noreply address or generic bot name. Mike Cannon-Brookes framed it as foundational: if you can't point to the person accountable for an automated action, you shouldn't be running that action yet.
Microsoft's warning adds the other half: agents can exfiltrate data, escalate privileges, or misuse credentials unless you treat them like any other insider threat. Attribution answers 'who approved this workflow,' but doesn't prevent the agent from accessing the wrong client file or sending to the wrong recipient. Both controls matter.
Sources: Atlassian's attribution announcement and Microsoft's insider-threat framing.
What it means for firm operations: every automated email gets a name
When your agent sends a payment reminder to a client 60 days overdue, that message should show it came from 'Jordan's assistant' or 'Emma's workflow'—not 'Accounts Receivable Bot' or a no-reply address. The difference is immediate when something goes wrong: if the invoice reference is incorrect, or the reminder was sent despite payment already received, the client knows who to call. Jordan owns the fix, not IT or 'the system.'
This applies across recurring workflows accounting firms pilot first:
- Weekly AR reminders — agent drafts overdue notices; the partner who approved the template owns escalations when a client disputes the balance.
- Month-end document requests — agent chases missing receipts or bank statements; the engagement manager who set the cadence reviews exceptions (client already sent it, or doesn't have access).
- Approval nudges for unsigned engagement letters — agent sends follow-up to clients who haven't signed; the partner on the engagement owns the conversation if the client has questions about scope or fees.
Without attribution, these comms feel impersonal and clients blame 'the firm's automation' when errors occur. With attribution, the relationship stays intact because there's a human name attached to every message—even if that human didn't personally draft it.
Decision framework: the four-step attribution audit
Before launching any client-facing agent, run this checklist with your ops lead and the partners who'll pilot automation:
- List every automated email type — invoice reminders, receipt requests, missing-document chases, approval follow-ups, late-fee notices. Write down the trigger (e.g., 'invoice unpaid 30 days') and the recipient (client, internal, both).
- Assign each type to a named owner — not a department, not 'the automation team.' The owner is the partner or manager who approves the message template and handles client escalations when the agent gets it wrong.
- Add attribution to email footers and agent profiles — 'Sent by Sarah's assistant' or 'This reminder was approved by Jordan Chen, who you can reach at jordan@firm.com.' Make the human visible.
- Weekly review cadence — the owner spot-checks sent items every Friday. Not IT, not the person who built the workflow. The partner who'll take the client call if something's off.
Don't launch an agent until someone claims it. That delay is the control: if no one's willing to put their name on the workflow, you've identified a process that isn't ready for automation yet.
Risk and control: what attribution solves (and what it doesn't)
Attribution addresses the accountability gap: when a client escalates a mistake, you need a name, not an alibi. But it doesn't prevent the mistake itself. An agent with the wrong client list will still send reminders to the wrong people, even if Sarah's name is on the message.
The trade-off is real: requiring ownership before launch slows rollout. You can't spin up ten agents across ten workflows and assign them all to 'operations' as a catch-all. Each workflow needs a specific human who understands the edge cases—what if the invoice was already paid yesterday? What if the client's on a payment plan we forgot to log?
Risk mitigation sequence: Start with low-stakes, internal-only workflows (Slack reminders to log time, calendar nudges for deadline approaching) before automating client-facing collections or compliance notices. Build the attribution habit on low-risk comms so partners get comfortable reviewing agent actions before you hand over invoice chasing.
Failure mode to avoid: Assigning ownership to 'the automation team' or 'IT' defeats the purpose. Clients and staff need a real person's name—the one who approved the workflow and will fix it when it breaks. If your firm doesn't have that person yet, the workflow isn't ready.
If you can't name the human accountable for an automated action, don't automate it yet. That constraint protects firms because the first time a client escalates a bot mistake, you need a name—not an excuse about algorithms.
Implementation path: pilot attribution with one partner's AR reminders
Pick one partner willing to test. Start with their overdue-invoice reminders over a 30-day cycle:
- Week 1–2: Human-in-the-loop on every message — agent drafts the reminder daily based on AR aging report. Partner reviews in Slack or email before the agent sends. Log false positives: wrong amount, invoice already paid, client on agreed extension.
- Week 3: Template approval, daily agent runs — if you've gone two weeks with zero escalations and fewer than 5% false positives, switch to 'approve the template once, agent runs daily.' Partner still gets a summary Slack message each morning: 'Sent 8 reminders today, flagged 2 as exceptions for your review.'
- Week 4: Spot-check only — partner reviews sent items every Friday, not daily. Measure time saved vs. manual reminders (typically 3–5 hours/week for a 200-client practice).
- Month 2: Expand to document requests — only after invoice pilot proves reliable. Same sequence: human-in-the-loop → template approval → spot-check cadence.
This aligns with how Anas structures pilots: fixed scope (map 3–5 workflows), fixed price (no hourly creep), and a clear decision gate before expanding. You're not automating everything at once—you're proving one partner can trust one workflow, then replicating that trust across the firm.
When attribution is wrong: over-applying ownership creates friction
High-volume, low-risk internal notifications don't need per-message attribution if the workflow is firm-wide policy. Examples:
- Slack reminders to log time by end of day
- Calendar blocks added 48 hours before tax deadlines
- Weekly summaries of unbilled hours sent to all staff
If twelve partners each 'own' identical quarterly tax reminders sent to all clients, you've added bureaucracy without control. Reserve named ownership for client-facing comms and anything involving money, compliance, or sensitive documents. Internal productivity nudges can run under 'Firm Operations' without individual attribution—as long as there's still a human who can turn them off or adjust the cadence when staff complain.
The test: does a mistake in this workflow require a specific partner to apologize to a client or fix a compliance issue? If yes, attribute it. If no (it's annoying but low-stakes), firm-wide ownership is fine.
Why this matters now: attribution solves the CYA problem before your first escalation
Atlassian's rule isn't about preventing AI errors—it's about who answers for them when they happen. For accounting firms, that distinction is everything. The moment a client forwards a bot mistake ('Why did I get a late-fee notice when I paid last week?') to their contact partner, you need a workflow owner who can say 'That was my automation, I approved the template, here's what went wrong, and here's the fix.'
Without attribution, that conversation defaults to 'the system made a mistake' or 'IT is looking into it'—both of which erode client trust faster than the time saved by automation. With attribution, the relationship stays personal even when the busywork is automated. The client still has a human to call, and that human still owns the outcome.
This aligns with the broader human-in-the-loop model for accounting firms: automate the repetitive (document requests, reminder sequences, routine follow-ups), but keep a named partner accountable for approving what goes out. Atlassian's protocol gives you the technical scaffolding to enforce that norm—agent profiles with visible owners, approval logs, review cadences.
If you're exploring automation for invoice reminders, receipt chasing, or client document requests, the attribution question is now non-negotiable: who owns this workflow, and are they willing to put their name on every message it sends? If the answer is 'IT' or 'no one yet,' you've found the constraint that keeps automation safe. Don't bypass it—use it to identify which workflows are ready and which need more process design before an agent touches them.
Ready to pilot automation with attribution built in? Get in touch to map your first workflow, assign ownership, and measure time saved without losing client trust. Or review common questions about approval gates and control before your next partner meeting.