DAILY NEWSLETTER · 2026-07-22 · AGENT ACCESS · LOCAL DATA BOUNDARY · LOOP EXIT CONTRACT

July 22 Operations Briefing — Agent Access Ledger, Local Boundaries, Loops That End

Today’s three themes cover the boundaries an agent needs before it starts work, while it runs, and when it says the work is done. Before execution, find access subjects beyond human accounts and connect each one to an owner and a revocation path. During execution, separate the local files an agent may read from the destinations to which it may send data. At exit, retain acceptance conditions, an attempt limit, a stop reason, a rollback point, and evidence.

Today’s operating points

Agent risk does not appear only when a model produces a wrong answer. Control is already unclear when an OAuth consent no one owns, a browser extension, or an old API-key reference remains in use. If a local agent can read broad folders with user privileges and no one distinguishes where its results may be sent, working convenience becomes authority to move data. A loop that retries without success criteria becomes a machine for accumulating changes and cost instead of solving a problem. The artifacts needed today are not a vast policy document but three practical records: an access ledger, a data-boundary card, and an exit contract.

1. Manage agent accounts, OAuth connections, browser extensions, API-key references, and service or other non-human identities in the same access ledger as human accounts.
2. Keep local read scope and outbound destinations as separate allowlists, then connect them to rules for logs, sessions, and cleanup after work or offboarding.
3. Let a loop retry automatically only when it has acceptance tests, a maximum attempt count, stop reasons, a rollback point, and result evidence.

1. Agent access needs an ownership ledger that reaches expiry and revocation

Microsoft Learn describes security within Microsoft Agent 365 and emphasizes visibility into agent identities, least privilege, responsible sponsors, and an access lifecycle that does not persist longer than needed. These are capabilities and operating directions stated for that product family, not universal controls automatically applied to every environment. The NIST AI Risk Management Framework is a voluntary framework intended to help incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems. NIST also states that AI RMF 1.0 is being revised. Read together, the operator question is not whether to copy a particular vendor console. It is whether the organization can find every agent access subject and connect it to responsibility, scope, and evidence of closure.

Source · Microsoft LearnSecure AI agents at scale using Microsoft Agent 365Covers agent-identity visibility, least privilege, sponsors, and access lifecycles within the Microsoft product family. Source · NISTAI Risk Management FrameworkIntroduces a voluntary framework for bringing AI risk management into organizational design, development, use, and evaluation, and notes its current revision status.

The first row records dedicated agent accounts that can sign in and agent identities issued by a platform. A display name is not enough. Include the actual directory or provider identifier, creation date, creator, current owning team, authentication method, connected resources, and last-used time. If automation reuses a personal account, record that rather than hiding it. The team can then separate personal access from automation ownership when an operator changes roles or leaves. Presence in the ledger does not mean approval. Separate discovered, under-review, and allowed states so that unidentified access is not mistaken for normal access.

The second group covers OAuth applications and consent, browser extensions, and API-key references. For OAuth, connect the application name to its client ID, approved scopes, consenting subject, token-using workflow, and revocation location. For a browser extension, record the installation ID, requested permissions, deployment method, profiles in use, and managing subject. Do not copy a raw API key into the ledger. Store only the secret-manager reference, consuming service, call destination, rotation date, and retirement procedure. Find stale key names and environment-variable references in documentation and code without spreading the secret value into another document or log.

The third group covers non-human identities that are less visible in human-facing consoles: service accounts, workload identities, robot users, and CI credentials. Because no person signs in with them every day, these subjects can quietly retain broad repository-write, cloud-deployment, or customer-data-read privileges for a long time. An access ledger should show owner, scope, expiry, and revoke_path on one line. Connect the owner to a real review responsibility, not just a team label. Describe both the named role and the actual resources in scope. If a credential has no technical expiry, give its access a reapproval date instead of disguising it as permanent.

Revocation evidence must be more concrete than a note saying someone clicked Delete. Record where and when the team confirmed that OAuth consent was withdrawn, tokens and keys were retired or rotated, service-identity role assignments were removed, and an extension left the managed profile. At task closure or an ownership change, connect every row to the same closure ticket. An expired primary credential can still leave a session or derived token valid, so verify termination with both the issuer and the destination service. Preserve a failed revocation attempt as well, letting the next operator see the remaining path immediately.

ZHS proposes an editorial access card with subject_type, subject_id, owner, scope, credential_ref, expiry, revoke_path, and revoke_evidence. These fields are neither a schema required by Microsoft or NIST nor a legal compliance checklist. They are a ZHS operating proposal for reconciling directory, secret-management, browser-management, and cloud-permission records in one review. The point is not the number of fields. It is a state in which every discovered access path shows both a responsible owner and a way to end it. Resolve a blank owner or revocation path before connecting another agent.

2. A local-file agent needs separate boundaries for folders it may read and destinations it may reach

Microsoft Foundry documentation explains how conversations, sessions, and stored data can be isolated by caller when multiple users share one hosted-agent endpoint. It also notes preview limitations and warns that data can mix if an application routes delegated users to the same session ID. Separate Defender for Endpoint documentation says that local AI agents can read files, invoke tools, and run commands with user privileges, and that malicious instructions in read content can hijack agent action. Its staged path from audit to blocking is product guidance for the stated licensing and supported Windows environment. These documents do not secure every local agent, but they provide concrete examples of why user, session, file, and action boundaries require separate tests.

Source · Microsoft LearnIsolate hosted agent sessions per user - Microsoft FoundryExplains caller-to-session mapping, per-user isolation of conversations and stored data, and cautions for delegated calls in Microsoft Foundry. Source · Microsoft LearnSet up AI agent runtime protection with Microsoft Defender for Endpoint - Microsoft Defender for EndpointCovers prompt-injection risk for local agents running with user privileges and an audit-to-block rollout within supported environments.

Start a local task card with allowed_folders. Name the repository, input directory, and temporary output directory needed for this task rather than granting “my computer” or an entire user home. Separate read from write access. The agent may read reference documents but not modify source media, while writing artifacts only into a dedicated directory. Check paths such as symbolic links, mounted cloud drives, and Downloads that can lead outside the apparent boundary. Do not mistake broad operating-system permission for approved task scope.

Next, maintain outbound_destinations as a separate list. Permission to read something locally is not permission to send it to an external model API, search provider, error collector, chat channel, or issue tracker. For each destination, record the host or service, data class sent, purpose of the call, and approval basis. Stop automatic transfer if a redirect or additional provider-side processing reveals a new destination at runtime. For summarization or classification that needs no outside transfer, evaluate a network-free path first. An allowlist does not replace firewall policy, but it gives the team a statement of intent against which to compare policy and actual traffic.

Discard the assumption that more logging is always safer. A full path, raw prompt, document body, access token, or user identifier copied into a log turns diagnostic data into a second data store. Retain what a decision needs: run ID, policy version, allowed or blocked action type, shortened target identifier, result state, and retention deadline. If reproduction truly requires a content excerpt, retain only the minimum segment under separate access control and give it a deletion date. Confirm that temporary debug mode is off after the task. Log minimization does not remove evidence; it reduces copies of source content that the decision never needed.

Review the login subject and the task subject together when defining a session boundary. When several users call an agent through one service credential, do not assume that platform-level isolation automatically follows. Test how the application binds a stable user identifier to a session, whether another user’s session ID is rejected, and whether a cache remains after a new login or logout. A local agent should likewise separate project working directories, temporary files, browser profiles, and tool sessions. If collaboration needs a shared session, make it an explicit choice with named participants and an end time, not an accidental result.

Offboarding does not end with disabling an account. At task closure, inspect temporary copies, caches, pending upload queues, running processes, browser logins, issued sessions, and local environment-variable references. When an operator changes roles or returns a device, run the revocation steps from the access ledger and deletion steps from the data-boundary card in the same ticket. ZHS proposes an editorial boundary card with allowed_folders, write_targets, outbound_destinations, log_fields, retention, session_owner, and offboarding_check. This is not a shared schema required by the two Microsoft documents; it is a ZHS proposal that translates different product examples into local operating questions.

3. The core of loop engineering is not repetition but a contract that can end

Addy Osmani’s article presents automations, isolated workspaces, skills, plugins and connectors, subagents, and state outside the conversation as components of long-running loops. It particularly emphasizes separating the maker from the checker and preserving tried, passed, and open states in an external record. This is one practitioner’s design view, not a standard proving that every tool offers the same function or assurance. Anthropic documentation recommends defining success criteria that are specific, measurable, achievable, and relevant, then designing evaluations that reflect real tasks and edge cases. It is likewise vendor guidance for working with Claude. Operators can use the two sources less as a recipe for “running forever” and more as support for writing what causes a loop to pass and what causes it to stop.

Source · AddyOsmani.comLoop EngineeringOffers one design view of long-running agent loops with isolated workspaces, maker-checker separation, and external state. Source · Anthropic DocsDefine success criteria and build evaluationsClaude vendor guidance on specific, measurable success criteria and evaluations shaped around real tasks and edge cases.

The first line of an exit contract is an acceptance test, not an artifact name. Replace “write the report” with observable conditions: all required sections are present, the six source URLs match, forbidden language is absent, and the rendered page remains intact. For code, separate the reproduced defect, existing contract, new behavior, and regression conditions. For research, separate confirmed facts from inference and require a primary source for each material claim. When success has several dimensions, preserve each pass result instead of hiding them in one average. One strength must not mask a critical failure.

The second line is an attempt budget. Set max_attempts and define what counts as one attempt. The team needs a consistent rule for whether three runs of the same command with different arguments are three attempts, or whether one edit-and-verification bundle is one. After each failure, record the observation, hypothesis, change, and result briefly. Stop when the same error and hypothesis repeat even if attempts remain. A limit is not a device for giving up early. It makes repetition without new information visible to a person.

The third line classifies stop reasons with values that can drive the next action: accepted, attempt_limit, repeated_failure, scope_change, permission_required, unsafe_input, dependency_unavailable, or operator_cancelled. Put free-form detail beneath the value. With only “done” and “failed,” a permission wait, external outage, and changed request collapse into one failure bucket. Recording “almost done” as success is equally dangerous because the next automated run may treat an incomplete artifact as its baseline. A stop reason is not an agent score. It is an operating signal for choosing resume, rollback, or discard.

The fourth line identifies a rollback point and evidence bundle. Establish a baseline commit or file hash, changed-file list, data-write targets, and external action IDs before work begins. After failure, decide whether reverting code is enough or whether created records, posts, messages, and uploads also need cancellation. Evidence includes acceptance-test results, the last change, the material error from each attempt, the input version, receipts for external actions, and remaining impact. Exclude secrets and unnecessary source content. Mark any irreversible action in the contract so that it requires separate approval before execution.

Separating maker and checker does not close a loop if exit authority remains unclear. The maker proposes a change and submits evidence. The checker reruns the original acceptance tests without rewriting them and chooses pass, reject, or hold. If the test itself must change, record a scope change and start again from a new baseline. ZHS proposes an editorial exit card with acceptance_tests, max_attempts, attempt_log, stop_reason, rollback_point, evidence_path, and reviewer. This is not a required schema from Addy Osmani or Anthropic. It is a ZHS proposal that turns their repetition and evaluation principles into an actionable handoff.

Operator memo

The smallest useful output to create today is a set of three cards. Put one current agent account, one OAuth connection, one browser extension, and one API-key reference on the access card. Attach an owner, scope, expiry or review date, revocation path, and last-use evidence to each row. Do not include the raw secret. Mark a blank as unconfirmed and assign an owner and deadline for checking it. Start with high-impact write, deployment, and external-transfer access rather than waiting for a complete inventory.

On the boundary card, choose one real task and record its read folders, write folders, outbound destinations, log fields, retention period, session owner, and closure check. Then test four failures safely: a request for a file outside the allowed folder, transfer to an unapproved destination, another user’s session ID, and a secret appearing in a log. Do not skip the card or test because a product offers isolation or blocking. Product controls operate under particular conditions; the operating boundary must connect those conditions to the actual task.

Put one active automated job on the exit card. Record acceptance tests whose result is clear to a human, the attempt ceiling, repeated-failure condition, stop reason for new authority, rollback point, evidence location, and final reviewer. The cards may live separately, but their identifiers should connect. An operator must be able to trace which access subject performed which job, inside which data boundary, under which exit contract. That connection comes before automation speed.

Today’s conclusion

The July 22 operating task is to reclaim ownership of the start, execution, and exit of agent work before delegating more. At the start, turn agent accounts, OAuth, extensions, API-key references, and non-human identities into a revocable access ledger. During execution, separate local read scope from outbound destinations and shorten the life of logs and sessions. At exit, close the loop with acceptance tests, an attempt ceiling, a stop reason, rollback, and evidence.

Choose one job today and connect the three cards. Name the owner and revocation path of its access subject, fix its allowed folders and outbound destinations, and state why it will stop and where it will roll back if it does not pass. With this small contract, an agent does not remain behind with forgotten authority, local data does not cross a boundary for convenience, and a loop ends in an explainable result instead of an endless retry.