Setup — rule-writing guide

Source: en/agent-approval/setup.md · Live: https://docs.1pass.dev/en/agent-approval/setup LLM-sanitized: internal links absolutized, VitePress containers → admonitions, line numbers in the Jump-to Index reference this rendered file (1-indexed).

📍 Jump-to Index

• L32-L67: ## The three principles of a good rule
  • L34-L44: ### 1. Amount — absolute value + rate of change
  • L45-L56: ### 2. Category — production / payment / public
  • L57-L67: ### 3. Time — outside business hours
• L68-L76: ## Where to write the rules
• L77-L125: ## 50 example rules
  • L79-L86: ### Payments / transfers
  • L87-L94: ### Advertising
  • L95-L103: ### Deployment / infrastructure
  • L104-L110: ### AI / external API cost
  • L111-L118: ### Data
  • L119-L125: ### Customer communication
• L126-L145: ## Anti-patterns
  • L128-L133: ### Too strict (zero usability)
  • L134-L139: ### Too loose (zero meaning)
  • L140-L145: ### Vague wording
• L146-L151: ## Monitoring changes

---

Setup — rule-writing guide

logi is not a policy engine. Business criteria such as "above what amount" or "which category" are something you write directly into the agent's prompt. logi provides only the "ask-and-receive" gate.

The three principles of a good rule

1. Amount — absolute value + rate of change

Request approval before any spend operation if:
- absolute amount > 1,000,000 KRW, OR
- change vs daily average > 20%, OR
- change vs last similar operation > 5x

An absolute value alone won't catch cases like "it was ₩1,000,000 yesterday and on average, but ₩50,000,000 today." The rate of change is your safety net.

2. Category — production / payment / public

Always request approval for:
- production environment (any DB migration, env var change, deploy)
- payment APIs (Stripe, Toss, PG)
- customer-facing copy changes (landing page, email templates)
- bulk operations (>100 records affected)

Classify by environment and blast radius. Safe categories like "test.echo" are fine to proceed automatically.

3. Time — outside business hours

Outside business hours (KST 09:00-18:00 weekdays):
- ALL writes to production
- ALL external API spend
- ALL bulk operations

An automated approval at 3 a.m. is overwhelmingly likely to be a human mistake.

Where to write the rules

Agent	Location
Claude Code	CLAUDE.md (project root) or ~/.claude/CLAUDE.md (global)
Codex CLI	AGENTS.md (project root)
Cursor	the .cursor/rules directory
Custom	the system prompt

50 example rules

Payments / transfers

- Any refund request (Toss/Stripe) → approval required
- Any single payment of ₩1,000,000 or more → approval required
- 3 or more payments to the same user within 24 hours → approval required
- Settlement data export → approval required

Advertising

- Meta ad budget change of ±20% or absolute ₩1,000,000 or more → approval
- Google Ads bidding strategy change → approval
- Replacing a Kakao Moment target audience → approval
- Pausing / resuming ads → approval (high revenue-impact action)

Deployment / infrastructure

- production DB migration → approval
- Bulk change to Render env vars → approval
- Vercel production deploy → approval
- GitHub Actions secret rotation → approval
- DNS record change → approval

AI / external API cost

- OpenAI API key rotation → approval
- A single API call of ₩100,000 or more (e.g. video generation) → approval
- Integrating a new external LLM → approval

Data

- production table DELETE / DROP / TRUNCATE → approval
- Bulk UPDATE of 1,000+ rows → approval
- Customer data export → approval
- Processing a GDPR delete request → approval

Customer communication

- Bulk email/SMS to 100+ recipients → approval
- Pricing policy change (landing page, terms, checkout screen) → approval
- Publishing an announcement (admin page) → approval

Anti-patterns

Too strict (zero usability)

BAD: Request approval before EVERY write operation.

→ The user ends up checking their phone every 30 seconds, and starts tapping [Approve] without thinking. That's user-side automation of MFA bombing.

Too loose (zero meaning)

BAD: Request approval before deleting the entire database.

→ You just wouldn't do that anyway. It fails to catch the genuinely wrong unit-of-spend approvals.

Vague wording

BAD: Request approval for "important" changes.

→ The AI has to infer what counts as important → zero consistency. Spell it out by absolute value, category, or time.

Monitoring changes

The "History" tab in the user's logi inbox shows every decision in chronological order. A rejection rate above 5% means the rules are too loose (the agent often attempts suspicious actions). A rejection rate of 0% with many approvals means the rules are too strict (the user is tapping [Approve] out of habit).