Autonomy should expand with evidence
Marketing agents can inspect websites, gather sources, classify prospects, draft content, prepare CRM updates, test pages, and monitor systems. These jobs can save time because their inputs and outputs are reviewable. The risk changes when the agent sends a message, publishes a claim, changes a live account, spends money, deletes data, or acts for the wrong client.
An approval gate is a designed control at that boundary. It is not a vague instruction to be careful. The workflow stops, presents the exact action and evidence, receives a decision from an authorized person, records the decision, and executes only the approved version.
Classify actions by consequence and reversibility
| Tier | Examples | Default control |
|---|---|---|
| Observe | Read a public page, retrieve allowed analytics, inspect a draft | Automatic with exact scope and access logging |
| Prepare | Summarize sources, draft an article, stage code, propose a CRM update | Automatic when output remains reviewable and isolated |
| Modify reversible | Update a noncritical field, create a test record, deploy to an approved staging target | Policy based authority with read back verification |
| Communicate or publish | Send email, post publicly, publish to a live property | Exact preview and explicit approval unless standing authority is documented |
| Spend or access | Change ad budget, grant permissions, consent to an integration | Human approval and account verification |
| Destructive or ambiguous | Delete records, replace broad data, act when client identity is unclear | Stop, verify target, preserve recovery, require explicit authority |
Risk depends on context. Editing a test property is different from changing a production contact owner. Publishing to a verified existing site is different from creating a new public property. The contract should name the target and environment.
Define what the approval must show
A useful approval request contains the requested action, exact target, proposed output, evidence freshness, material uncertainty, expected consequence, and recovery path when relevant. It should be short enough to review and specific enough to prevent approval from becoming a blank check.
- Identity: client, account, portal, repository, domain, recipient, or publication property.
- Action: send, publish, update, delete, spend, grant, or execute.
- Preview: exact message, page, field change, amount, or command result.
- Evidence: source links, timestamps, tests, and current state.
- Uncertainty: missing facts, conflicts, and assumptions that affect the decision.
- Recovery: draft retention, backup, previous deployment, or rollback path.
Treat outreach and client communication as exact delivery
An agent can research a business and prepare a personalized draft. Before sending, the workflow should verify the recipient, thread, reply routing, subject, body, attachments, signature, and evidence. Approval applies to the exact preview. If the content or recipient changes, request a new decision unless the person has explicitly authorized the change.
Drafting is not sending. Saving a local specification is not creating a mail draft. Creating a mail draft is not external delivery. A receipt should preserve those states and read back the final sent message when delivery is approved.
Require stronger gates for publishing and spend
Publishing creates a public record and can affect search, reputation, and legal exposure. Verify the exact domain, page, claim sources, dates, structured data, links, and live result. A standing approval can cover a clearly named existing property and bounded type of change, but it should not silently extend to another client or a new site.
Advertising changes money and platform behavior. Start read only. Verify the account, campaign, conversion definitions, reporting dates, and tracking health before recommending a change. Show the proposed amount, date range, objective, and expected guardrails. Never infer authority to change spend from permission to inspect performance.
Human authentication gates stay human
Routine account selection and approved password manager autofill can be part of an established workflow. Multi factor prompts, passkeys, CAPTCHA, recovery codes, new consent, and push approvals require a person. Agents should not silently retrieve one time codes from email or expose secrets in prompts, logs, source files, or receipts.
After access, the workflow still needs the exact account and capability scope. A valid login is not permission to act across every connected client. Record nonsecret access metadata and keep credentials in an authorized secret manager.
Design explicit failure states
A worker should stop on ambiguous identity, unavailable primary evidence, authentication gates, missing permissions, conflicting instructions, unsafe targets, and failed verification. Stopping is useful when the receipt explains what succeeded, what remains incomplete, why continuation is unsafe, and the one decision or state change required.
Do not convert an unknown state into success. A configured integration is not proof that a workflow ran. A deployment command is not proof that the live URL changed. A 200 response is not proof that the right record was updated. Verification should inspect the final artifact or state.
Use receipts to earn broader autonomy
Every run should return the job, exact scope, sources, actions, output, tests, external state, and remaining uncertainty. Use status labels consistently: prepared, drafted, staged, approved, sent, published, verified live, blocked, failed, or rolled back.
Review repeated runs for routing accuracy, source quality, false certainty, intervention rate, error recovery, and business value. Broaden authority only when the workflow demonstrates reliable behavior inside its current boundary. If the environment, account, or consequence changes, reassess the gate.
A minimum governance implementation
- Inventory agent actions and classify their consequence, reversibility, and data sensitivity.
- Assign exact identities, allowed tools, client boundaries, and output contracts.
- Set read only or draft mode as the default for new workflows.
- Place approval immediately before consequential tool execution.
- Bind approval to an exact target and preview with an expiration or run identifier.
- Read back the external state after execution and return a structured receipt.
- Review failures and interventions before expanding authority.
Good governance does not prevent useful automation. It makes useful automation repeatable because the business can see where the worker is allowed to move and what proves the job was completed.
Primary official sources
These sources support the platform, standards, and implementation guidance in this article. Product behavior and documentation can change, so confirm the current source before a consequential implementation.
- NIST AI Risk Management Framework (National Institute of Standards and Technology)Primary framework for mapping, measuring, managing, and governing AI risk.
- Artificial Intelligence Risk Management Framework: Generative AI Profile (National Institute of Standards and Technology)NIST generative AI risk profile and actions.
- Webhooks API guide (HubSpot Developers)Official event and integration behavior for a common marketing system.
- OpenAI safety best practices (OpenAI Platform)Official guidance on human review, adversarial testing, and constrained inputs and outputs.