A documentation agent needs to edit a page. Giving it your repository token may also let it change CI workflows, push unrelated code, or keep making changes after the documentation task ends. The requested task is small. The inherited authority may be much larger.

That gap is worth revisiting this week. In its November 5 security update, Microsoft describes Dynamic Permissions that scope an agent’s authority to its current task and its duration. The same update discusses operating-system-enforced containment through Microsoft Execution Containers. These are vendor descriptions, not independent evidence that a deployment is secure. But they put a useful engineering question in focus: what, exactly, ends an agent’s permission to act?

Give the task a permission lifecycle

A standing credential usually answers whether an account can perform an operation. An agent workflow also needs to establish which task the operation belongs to, which resources that task covers, and whether the authorization is still valid.

For the documentation change, a grant might authorize one agent to read and write one document for a short period. It should not authorize workflow edits or deployment. Completing or cancelling the task should revoke the grant immediately, even if its time limit has not expired. A retry tomorrow should require a new grant rather than quietly reuse yesterday’s access.

Microsoft’s October 19 announcement describes this separation explicitly: the employee retains their access while the agent receives its own task-scoped, time-bound authority. You do not need to adopt that product to apply the design principle in a tool gateway or application service.

A small policy example you can run

The following Python 3.10+ example models the decision before a tool call. It uses an exact resource identifier instead of a path-prefix rule, and a supplied integer clock so the expiry test is reproducible. It makes no network calls and changes no files.

from dataclasses import dataclass


@dataclass(frozen=True)
class Grant:
    agent: str
    task: str
    actions: frozenset[str]
    resources: frozenset[str]
    expires_at: int


def allowed(grant, *, agent, task, action, resource, now, revoked):
    return (
        not revoked
        and now < grant.expires_at
        and agent == grant.agent
        and task == grant.task
        and action in grant.actions
        and resource in grant.resources
    )


grant = Grant(
    agent="docs-agent",
    task="docs-482",
    actions=frozenset({"read", "write"}),
    resources=frozenset({"repo:demo/docs/intro.md"}),
    expires_at=200,
)
base = dict(
    agent="docs-agent", task="docs-482", action="write",
    resource="repo:demo/docs/intro.md", now=100, revoked=False,
)
cases = [
    ("in scope", {}, True),
    ("other resource", {"resource": "repo:demo/.github/workflows/ci.yml"}, False),
    ("other task", {"task": "docs-483"}, False),
    ("other agent", {"agent": "build-agent"}, False),
    ("other action", {"action": "delete"}, False),
    ("expired", {"now": 200}, False),
    ("revoked", {"revoked": True}, False),
]
for label, changes, expected in cases:
    result = allowed(grant, **(base | changes))
    assert result is expected, label
    print(f"{label}: {'ALLOW' if result else 'DENY'}")

Running the example produces:

in scope: ALLOW
other resource: DENY
other task: DENY
other agent: DENY
other action: DENY
expired: DENY
revoked: DENY

The permitted write passes. Changing the resource, task, agent, or action fails. Access also fails at the expiry boundary and after revocation. Those denial cases belong in tests alongside the successful operation; testing only the happy path would miss most of what this policy is supposed to do.

Keep the enforcement outside the agent

This function is a teaching example, not a sandbox or a secure token system. A frozen Python object does not make a grant trustworthy if the agent controls the process. In a real deployment, a trusted service must issue and store the grant, authenticate the calling agent, supply the clock and revocation state, and derive the resource from the actual operation. The model must not choose those values or edit the policy.

The gateway must check every operation before executing it, including calls from plugins or delegated agents. It also needs to prevent bypass: an agent that holds the underlying broad repository token can skip your narrow wrapper and call the API directly. Keep that credential in the trusted gateway and expose only the permitted operations to the agent.

Resource identifiers need careful handling too. If a tool accepts file paths, the enforcement layer must account for path traversal and symlinks rather than trust a string that appears to point inside the workspace. Authorization must cover the resource actually opened. Revocation and execution need coordination, since a check followed by a delayed write can otherwise race with task cancellation.

Containment addresses another part of this problem. The Windows Developer Blog’s October 7 MXC explanation describes policies enforced independently of the agent across files, processes, and network access. It also distinguishes enforcement from permissive observation. Recording that an operation would have been denied is not the same as blocking it.

A prompt for reviewing your own tool boundary

Use this with an agent that can inspect your tool implementation and tests. It asks for evidence rather than a promise that the system follows least privilege.

Review the authorization boundary for [agent workflow].

Authorized task: [task and completion condition]
Permitted actions and resources: [explicit list]
Expiry and cancellation rules: [rules]
Tool gateway and credential storage: [files or services]

Trace one allowed operation and one denied operation.
Identify who supplies the agent identity, resource, clock,
and revocation state. Check whether the agent can alter
these values or bypass the gateway with another tool.

Run tests for wrong resource, wrong task, wrong agent,
wrong action, expiry, and cancellation when tools permit.
Report the actual results and any checks you could not run.
Do not call the boundary secure solely because a prompt
tells the agent to stay within scope.

A prompt can organize that review, but it cannot enforce the resulting policy. Before granting a real agent write access, test that an out-of-scope write is blocked at the service or operating-system boundary, then repeat the check after cancellation. Record the task, requested action, policy decision, and result without copying credentials or sensitive document contents into the log.

For the documentation agent, the practical target is specific: it can update the authorized document while the task is active, cannot change the CI workflow, and loses write access when the task ends. Those are behaviors you can test before giving it a credential with broader reach.