← All briefings2026-08-24

How Much Authority Should You Give an AI Agent? Start With Read-Only Access and Earn the Right to Automate

AI agents are becoming easier to connect to customer records, inboxes, workflow platforms, internal knowledge, and business systems. The difficult question is no longer whether an agent can complete a task. It is whether

The Operator Signal

Several recent developments point toward the same operating model:

• Treat every agent as a separate worker with limited permissions.

• Keep consequential actions behind deterministic rules and human approval.

• Make work visible outside the chat window.

• Test repeated runs, including failure cases, before expanding authority.

• Verify the data-retention behavior of every endpoint and feature—not merely the vendor’s general privacy promise.

The practical decision for a small or midsize business is straightforward: begin with an agent that reads approved information and prepares recommendations or drafts. Do not begin with an agent that independently sends, pays, refunds, deletes, publishes, or changes a system of record.

That may sound conservative. It is actually the fastest credible route to useful automation because it lets a business discover data, routing, and process problems before those problems create customer-facing consequences.

What Changed

1. A workflow-platform release highlighted the importance of credential boundaries

On August 21, n8n released version 2.35.6 with several core fixes. One addressed resolving end-user credentials when loading node parameters. The release also included environment-value normalization and additional isolation around a trigger’s closing function.

Verification status: Confirmed in the official GitHub release notes. The notes identify these as bug fixes. They do not describe a publicly exploited security incident, so it would be inaccurate to characterize the release that way.

Why it matters: Credentials are where an apparently simple automation becomes operationally consequential. A workflow may have access to several users, accounts, or business systems. If credentials are resolved incorrectly, the workflow can operate under the wrong authority even when its language output looks perfectly reasonable.

This is also a reminder that permissions are not a one-time setup task. Workflow engines change, integrations change, and credentials rotate. An automation that passed testing six months ago may not have the same behavior after a platform upgrade.

Analysis: Businesses should treat workflow identity as part of the process design. “The automation can access the CRM” is too broad. The better questions are:

• Which account does it use?

• Which records can it read?

• Which fields can it change?

• Can it act for multiple users?

• Can its credential access be reviewed and revoked independently?

• What happens after the workflow platform is upgraded?

Act: Inventory every credential attached to an AI-assisted workflow. Separate read credentials from write credentials where the platform permits it.

Watch: Release notes involving credential resolution, environment configuration, isolation, execution context, or authentication.

Ignore: The assumption that a no-code interface makes permission design automatic.

2. OpenAI expanded the conversation around Zero Data Retention—but eligibility and endpoint behavior still matter

OpenAI announced on August 19 that it was offering Zero Data Retention for frontier models to eligible API customers. Its current API documentation provides the operational detail behind that announcement.

By default, OpenAI says API abuse-monitoring logs may contain prompts, responses, and derived metadata and may be retained for up to 30 days, subject to stated exceptions. Eligible, approved customers can request Modified Abuse Monitoring or Zero Data Retention.

The documentation also says Zero Data Retention changes certain endpoint behavior. For example, the `store` parameter for Responses and Chat Completions is treated as false. But some endpoints and capabilities remain ineligible and can retain application state.

Verification status: The August 19 announcement is confirmed through OpenAI’s official news feed. Retention conditions and endpoint distinctions are confirmed in OpenAI’s API documentation. These are vendor statements about its own service.

Why it matters: “The vendor does not train on our business data” and “the system retains no customer content” are not equivalent statements.

An AI workflow can create data in several places:

• The model provider’s logs

• Stored application state

• The workflow platform’s execution history

• A vector database or knowledge store

• Error-monitoring and observability tools

• Email, CRM, ticketing, and document systems

• Human review queues and exported reports

Changing one provider setting does not remove the other copies.

Uncertainty: Eligibility, contractual terms, regional availability, endpoint support, and safety-related exceptions can change. Businesses handling regulated or contractually restricted information should obtain current written terms rather than rely on a general product page.

Act: Create a simple data-flow map for one AI workflow. Record every system that receives the input, generated output, logs, attachments, and approval history.

Watch: Endpoint-specific retention eligibility and newly introduced stateful features.

Ignore: Blanket privacy conclusions based solely on the model name, plan name, or a sales phrase such as “enterprise-grade.”

3. Google published a zero-trust pattern for agents that can change production systems

On August 17, Google published technical guidance and an open-source example for a customer-support and returns agent built with its Agent Development Kit.

The example considers an agent that can calculate a refund, write to a database, and execute generated code. Google’s proposed defense-in-depth design has three parts:

• A distinct cryptographic identity for state-changing writes

• Isolated execution for dynamically generated code, with no network access and strict resource limits

• Deterministic gateways that enforce business rules around model inputs and outputs

Google explicitly argues that a system prompt such as “never refund more than the order total” is not a sufficient security boundary.

Verification status: Confirmed as official Google technical guidance and example code. It is a proposed architecture, not proof that every deployment using these components will be secure.

Why it matters: Most smaller businesses do not need hardware-backed signatures for a first AI experiment. They do need the principle behind them: the model should not be the final authority on whether its own action is permitted.

If an agent proposes a discount, refund, account change, or outbound message, a separate control should decide whether the action is allowed. That control might be:

• A fixed monetary ceiling

• A list of approved templates

• A customer-status rule

• A role-based approval

• A required record match

• A prohibition against sending attachments

• A rule that blocks bank, identity, health, or credential data

• A human review step

These controls should be enforced by workflow logic or application permissions—not hidden inside a prompt the model can misinterpret.

Act: Move critical rules out of prompts and into deterministic workflow checks.

Watch: Whether your platform can assign separate identities, scopes, logs, rate limits, and approval policies to each automation.

Ignore: Claims that a carefully worded prompt can substitute for access control.

4. GitHub made the case for visible, durable agent workflows instead of chat-only execution

In an August 17 practitioner article, GitHub described using “canvases” to make agent work visible, persistent, steerable, and approvable.

The article’s repeatable pattern is relevant beyond software development:

• Define workflow states.

• Surface important decisions.

• Persist drafts and progress.

• Establish explicit human approval points.

The author also disclosed that the example canvases required significant AI-credit consumption—about 2,000 credits for one example and 3,000 for another—while arguing that reusable workflow structure can reduce later rework.

Verification status: Confirmed as a GitHub-authored practitioner account. The credit figures are the author’s examples, not general cost benchmarks or guaranteed savings.

Why it matters: Chat is useful for giving instructions, but it is weak as an operational record. After several turns, it can become difficult to determine:

• Which version is current

• What evidence the agent used

• What it changed

• Whether a person approved the change

• What remains blocked

• How much work or model usage the task consumed

For a customer-facing workflow, these should be fields and states—not facts buried in a transcript.

A basic lead-follow-up process, for example, might use the states:

1. New inquiry

2. Information verified

3. Draft prepared

4. Human review required

5. Approved

6. Sent by the existing messaging system

7. Outcome recorded

8. Escalated or closed

That structure limits ambiguity and makes cost, delay, and failure visible.

Act: Give every AI-assisted process a visible status, owner, evidence field, draft field, approval field, and final outcome.

Watch: Token or credit consumption per completed business outcome, not merely per conversation.

Ignore: The idea that a long chat transcript is an adequate audit trail.

5. PagerDuty’s repeated testing found a silent agent-routing failure that a few demonstrations would have missed

PagerDuty published an engineering experiment on August 12 comparing two ways of delivering standards to an AI coding agent: one unified skill versus several domain-specific skills.

Its reported conclusion was not that one set of instructions produced dramatically better work. When the correct skill loaded, the variants were effectively tied. The material difference was selection reliability: in three domain-specific trials, no skill loaded at all, and compliance dropped sharply.

PagerDuty reports that the broader work included 276 trials. It also describes a chain of custody in which scripts extracted deterministic metrics, a separate model scored rubric-based dimensions, and humans made the final decision after reviewing the evidence.

Verification status: This is a detailed company-reported experiment, not an independent peer-reviewed study. PagerDuty appropriately states that its result covered one codebase and task family and should not automatically be generalized to every agent.

Why it matters: An AI workflow can look successful while silently skipping a required source, policy, or tool.

In an ordinary business process, equivalent failures might include:

• Drafting a reply without checking the latest account note

• Quoting from a general price list instead of the customer’s agreement

• Missing a required escalation rule

• Preparing a follow-up without loading consent status

• Using old company policy from model context instead of the approved knowledge base

One successful demonstration will not expose intermittent routing failures. Repeated tests using the same input are necessary because agent behavior can vary between runs.

Act: Repeat the same test cases and record whether every required source and rule was actually used.

Watch: Silent omissions. A fluent answer is not evidence that the required process was followed.

Ignore: “It worked in the demo” as an approval standard for production access.

The Business Problem This Creates

Many businesses are trying to automate a visible task—follow up with leads, answer service questions, summarize reports, prepare quotes—when the underlying problem is actually workflow control.

Consider lead handling. A typical business has information spread across form submissions, email, a CRM, call notes, calendars, price sheets, and individual employee knowledge. An agent may be able to draft an excellent response, but several management questions remain:

• Is this person allowed to be contacted?

• Is the inquiry genuine or spam?

• Which service, territory, or account owner applies?

• Is the price current and approved?

• Did the agent use private information that should not appear in an email?

• Is it making a promise about schedule, scope, availability, or outcome?

• Who is responsible if the response is wrong?

• Can the business reconstruct what happened later?

Giving the agent more autonomy does not resolve those questions. It makes unresolved process rules execute faster.

The safer operating model separates the work into four layers:

1. Information access: The agent reads only the records required for the task.

2. Reasoning and drafting: It classifies, summarizes, recommends, or prepares a draft.

3. Policy enforcement: Deterministic rules block prohibited data and unauthorized commitments.

4. Commitment: A human or tightly controlled application action sends, changes, pays, publishes, or approves.

This division also makes cost control easier. If the agent repeatedly fails at information access, there is little value in buying a more capable model. If drafts are accurate but approvals take too long, the bottleneck is the review process. If the same questions recur, the company knowledge may need repair before further automation.

Workflow to Test

A bounded lead-follow-up drafting experiment

Run a two-week test in which AI prepares follow-up drafts but cannot send messages or change customer records.

Input

Use a controlled set of new inquiries or previously handled examples containing only the fields needed for drafting:

• Contact name or approved identifier

• Inquiry text

• Service category

• General service area

• Lead source

• Contact-consent status

• Approved company FAQ or knowledge excerpts

• Current, approved response templates

Start with synthetic or properly de-identified examples. Move to limited live records only after privacy and permission review.

AI task

Ask the agent to:

1. Classify the inquiry by service category and urgency.

2. Identify missing information.

3. Cite the approved company source used for each factual statement.

4. Draft a response without sending it.

5. Flag any request involving price, legal terms, complaints, refunds, safety, scheduling commitments, or sensitive data.

6. Return “insufficient approved information” rather than inventing an answer.

Human approval

A designated employee reviews:

• Correct recipient

• Consent and contact channel

• Factual accuracy

• Source citations

• Tone

• Sensitive information

• Any commitment involving price, scope, schedule, policy, or outcome

The human edits or rejects the draft. Sending remains a separate action in the normal email, CRM, or messaging system.

Success measure

Track business outcomes rather than general impressions:

• Percentage of drafts approved without factual correction

• Percentage using the correct approved sources

• Percentage correctly escalated

• Median review time

• False-confidence incidents

• Duplicate or misrouted drafts

• Model and workflow cost per approved draft

• Follow-up time compared with the prior process

Do not use response rate or sales conversion alone to judge the agent. Those outcomes are influenced by lead quality, offer, timing, market conditions, and human follow-through.

Stop condition

Pause the test immediately if the workflow:

• Uses the wrong person’s information

• Includes restricted or unnecessary personal data

• Invents a price, policy, qualification, or availability statement

• Bypasses the approval step

• Selects the wrong account or credential

• Sends a message automatically

• Fails to show which approved source it used

• Produces repeated confident errors after correction

A high-risk failure should not be averaged away by many acceptable drafts.

Who should use this test

This is suitable for businesses with:

• A repeatable inquiry process

• An identifiable human reviewer

• Approved source material

• A manageable volume of leads

• A workflow platform that can keep sending disabled

• Enough logging to review inputs, outputs, and decisions

Who should not use it yet

Do not use live data if the business cannot identify where the information is stored, who has permission to access it, or what the vendor retains.

This experiment is also inappropriate as written for emergency, medical, legal, financial, employment, or safety-critical decisions. Those require specialized governance and professional review.

What Must Stay Private or Human-Approved

Keep these data categories restricted

• Passwords, API keys, private keys, session tokens, and recovery codes

• Full payment-card or bank information

• Government identification numbers

• Health, legal, disciplinary, or employment records

• Customer data unrelated to the immediate task

• Private contract terms unless the workflow is specifically authorized for them

• Raw inboxes, shared drives, or databases when a narrower view is possible

• Internal security configurations and incident details

• Unredacted workflow logs containing customer content

Limit these permissions

• Sending email, SMS, or direct messages

• Publishing to websites or social accounts

• Creating, editing, or deleting CRM records

• Exporting customer lists

• Reading all users’ credentials

• Installing integrations or agent tools

• Executing generated code

• Accessing the open internet while handling sensitive records

• Changing permissions, retention settings, or workflow rules

Require human approval for these commitments and actions

• Prices, discounts, refunds, credits, and payments

• Contract or policy interpretations

• Appointment and delivery guarantees

• Scope changes

• Complaint resolutions

• Hiring, firing, discipline, or employee evaluation

• Legal, health, financial, or safety guidance

• Account suspension or deletion

• Public statements and reputation responses

• Any irreversible or difficult-to-recover action

Whenever possible, the approving person should see the source record, proposed action, relevant policy, and changes in one review screen.

One Operator Decision

Implement a read-only, draft-only agent for one repeated workflow, with visible evidence and mandatory approval. Require it to pass repeated normal, edge-case, and malicious-input tests before considering any additional authority.

Do not make “fully autonomous” the goal. Make reliable completion, controlled access, faster review, and recoverable errors the goals. Greater authority should be earned one permission at a time.

Repurposing Hooks

Podcast opening question:

If an AI agent can read your CRM and draft a customer response, what evidence should it produce before anyone trusts it to press Send?

YouTube hook:

The biggest mistake in AI automation is not choosing the wrong model. It is giving a convincing model the wrong permissions.

Three quotable takeaways:

• “A prompt tells an agent what it should do; a permission boundary determines what it can do.”

• “A fluent answer is not proof that the agent checked the required source.”

• “Do not start by automating the commitment. Start by automating the preparation and preserving the approval.”

Source Index

• [n8n] - https://github.com/n8n-io/n8n/releases/tag/n8n%402.35.6 - August 21, 2026 - Official release notes confirming core fixes involving end-user credential resolution, environment-value parsing, and trigger isolation.

• [OpenAI News RSS] - https://openai.com/news/rss.xml - August 19, 2026 - Official announcement signal that OpenAI was offering Zero Data Retention for frontier models to eligible API customers.

• [OpenAI API Documentation] - https://developers.openai.com/api/docs/guides/your-data - Accessed August 24, 2026 - Endpoint-specific details on abuse-monitoring retention, application state, eligibility, configuration, and limitations of Zero Data Retention.

• [Shubham Saboo and Eric Dong, Google Developers Blog] - https://developers.googleblog.com/build-zero-trust-ai-agents-with-googles-agent-development-kit/ - August 17, 2026 - Google’s zero-trust agent pattern using separate identity for writes, isolated code execution, and deterministic semantic gateways.

• [Ayan Gupta, GitHub Blog] - https://github.blog/ai-and-ml/github-copilot/how-canvases-make-agentic-workflows-visible-steerable-and-cost-efficient/ - August 17, 2026 - Practitioner guidance on persistent workflow states, visible decisions, explicit approvals, and agent-workflow cost.

• [Sarah Martinelli Benedetti, PagerDuty Engineering] - https://www.pagerduty.com/eng/evidence-over-anecdotes-running-a-b-tests-on-ai-agent-tooling/ - August 12, 2026 - Company-reported repeated experiment showing that silent skill-selection failures, rather than output quality when correctly routed, determined the result.