Authority Policy

The core idea

When AI Partner acts as you — sending email, replying to Slack DMs, joining meetings, placing phone calls — it needs to know what it's allowed to do alone and what requires your sign-off.

The Authority Policy is your answer to that question. It's a simple text file (workspace/AUTHORITY.md) with three sections:

• Auto — execute immediately, no interruption, audit-logged
• Draft + ask — draft the action, send it to you via Telegram for a one-tap approval
• Block — never do this, no matter what

Every action that touches the real world runs through this gate first.

---

The decision flow

Agent intends to act (e.g., reply to an email from your boss)
       │
       ▼
AuthorityPolicy.evaluate({ action: "reply_email", counterparty: "boss" })
       │
       ├─ verdict: "auto"
       │    → Execute immediately
       │    → Log to authority_decisions table
       │    → Done
       │
       ├─ verdict: "draft_and_ask"
       │    → Draft the action (compose reply, prepare message)
       │    → Send to ConfirmationChannel (your Telegram bot)
       │    → You see: preview + 3 buttons
       │         ┌──────────┬────────────┬──────────┐
       │         │ ✅ Approve │ ✏️ Edit    │ ⏭ Skip  │
       │         └──────────┴────────────┴──────────┘
       │    → "Approve" → sends as-is
       │    → "Edit" → reply with your correction → sends that instead
       │    → "Skip" → leaves it for you to handle manually
       │    → Timeout (default 10 min) → fallback action (usually skip)
       │
       └─ verdict: "block"
            → Refused entirely
            → Notification sent to you: "I was asked to [X] but it's blocked"

The agent never sends a message, moves money, or makes a commitment without hitting this gate first.

---

The AUTHORITY.md file

Edit this in Settings → Workspace → AUTHORITY.md or directly at workspace/AUTHORITY.md. Changes take effect immediately — the file is hot-reloaded without restart.

## Auto
- action: read_.*
- action: archive_message
- action: send_message + counterparty: family

## Draft + ask
- action: reply_email + counterparty: colleague
- action: reply_email + counterparty: client
- action: send_slack_dm + counterparty: colleague
- action: send_telegram_dm + counterparty: vendor

## Block
- action: payments.*
- action: legal_commitment
- action: delete_.*  + scope: production
- action: place_phone_call

Rule syntax

Each rule is action: <pattern> optionally combined with counterparty: <class>:

Field	Values	Notes
action	Any action name or glob pattern	read_.* matches all read actions; payments.* blocks all payment actions
counterparty	family, colleague, client, vendor, unknown, public	Relationship class from CounterpartyStore
scope	production, staging, personal, etc.	Optional context qualifier

Rules are evaluated top to bottom. The first match wins.

---

Counterparty classes

Every person AI Partner interacts with on your behalf is resolved to a counterparty record with a relationship class. The CounterpartyStore links Bob's Slack username, bjones@acme.com, and his Telegram handle to one canonical record.

You assign a class when the person is first encountered (or AI Partner infers it from context):

Class	Examples
family	Spouse, parents, siblings
friend	Personal contacts
colleague	Coworkers, direct reports
client	Customers, paying users
vendor	Suppliers, service providers
investor	VCs, angels, board members
unknown	Anyone not yet classified
public	Broadcast channels, mailing lists

Start conservative: block everything except reads, then open up categories as you build confidence. You can always change the policy without restarting.

---

Example policies by persona

## Auto
- action: read_.*
- action: archive_message
- action: web_search
- action: send_message + counterparty: family

## Draft + ask
- action: reply_email + counterparty: investor
- action: reply_email + counterparty: client
- action: reply_email + counterparty: colleague
- action: send_slack_dm + counterparty: colleague
- action: join_meeting + counterparty: investor

## Block
- action: payments.*
- action: legal_commitment
- action: place_phone_call
- action: delete_.* + scope: production

---

The Telegram approval interface

When a draft_and_ask verdict fires, you get a Telegram message like this:

AI Partner — Approval Required

📧 Reply to email from sarah@acme.com

Preview:
> Hi Sarah,
> Thanks for sending the proposal over. I've reviewed it
> and I'm happy to move forward — can we schedule a call
> this week to discuss terms?
> 
> Best,
> Alex

[✅ Approve]  [✏️ Edit]  [⏭ Skip]

• Approve — sends the draft exactly as shown
• Edit — reply with your corrected text, then the agent sends that version
• Skip — marks the action as deferred; the agent moves on and leaves this for you

If you don't respond within the timeout period (default: 10 minutes), the fallback action fires — usually skip. You can configure the timeout and fallback in Settings → Authority Policy.

---

The audit log

Every authority evaluation is logged to the authority_decisions table — whether it was auto, draft+ask, or block. You can review the full history in Settings → Audit Log.

Financial write operations (Stripe, HubSpot, S3, Sentry, Outlook) are additionally logged to a tamper-evident financial_audit_log table.

---

Setting it up

1. 1
   Connect your Telegram bot

   Go to Settings → Messaging → Telegram and enter your bot token (from @BotFather) and your Telegram chat ID. This enables the ConfirmationChannel.

2. 2
   Edit AUTHORITY.md

   Go to Settings → Workspace and edit the AUTHORITY.md file. Start conservative — block everything except reads, then open up specific action+counterparty combinations as you become comfortable.

3. 3
   Test it

   Ask AI Partner to "draft a reply to [a colleague]'s latest email". With draft_and_ask in place, you should receive a Telegram approval request within seconds.