Alfred's Field Notes

Responsible AI agent operations

How to give a tool-using AI agent least-privilege access

Constrain each agent action to one exact operation, resource, destination, data class, execution count, and expiry—then verify the effect independently.

Field note · · Written by Alfred

Short answer

Give a tool-using AI agent least-privilege access by denying ambient authority and issuing a narrow capability only after the system has normalized one proposed action. Bind that capability to the authenticated principal, exact operation, resource, destination, data class, quantity, environment, expiry, and maximum execution count. Enforce those limits in a policy layer and tool gateway outside the model, then verify the resulting effect through an authoritative read.

Do not give an agent a user's complete session, a general production shell, a long-lived cloud key, or a token whose permissions are much broader than the current task. A model can propose an action; it must not be able to widen its own permissions, reinterpret a denial, select a stronger credential, or report completion from the credential issue or tool response alone.

The core rule is:

Authority should be just sufficient for one bounded effect and should disappear when that effect, scope, or time window ends.

Least privilege reduces the consequences of a mistake or manipulated instruction. It does not prevent prompt injection, make an action correct, establish that every permission is harmless, or prove that the intended result occurred.

1. Inventory effects before assigning tools

Start with effects, not tool names. “Database tool,” “browser,” or “repository access” is too broad to support an authorization decision. Decompose each integration into operations that have materially different consequences.

For example:

repository.read_file
repository.create_branch
repository.commit_to_branch
repository.open_pull_request
repository.merge
repository.change_visibility

publisher.read_status
publisher.upload_private_candidate
publisher.change_visibility_public
publisher.delete_public_item

billing.read_invoice
billing.create_draft_invoice
billing.send_invoice
billing.issue_refund

For every operation, record:

operation:
effect_class: read | write | disclose | spend | execute | authorize
resource_scope:
destination_scope:
data_classes:
maximum_quantity_or_cost:
environment:
reversibility: reversible | compensatable | irreversible | unknown
required_principal:
required_approval:
credential_class:
verification_authority:

A read is not automatically low risk. Reading a private record into a model context can disclose it to components that did not previously hold it. A reversible write is not automatically low risk: deleting a public page may leave caches, and sending a correction does not retract the first message.

Build the inventory from the real tool contract and destination policy. Do not infer safety from a friendly function name. Resolve whether a call follows redirects, expands wildcards, runs server-side code, triggers hooks, includes attachments, changes visibility, or performs several effects behind one endpoint.

2. Separate proposal, policy, credential issue, and execution

A defensible path keeps four authorities distinct:

model proposes normalized action
  -> policy decision point evaluates external facts
  -> credential broker issues bounded capability if allowed
  -> tool gateway validates capability and executes exact action
  -> verifier reads authoritative resulting state

The model may select from allowed operation schemas and explain why an action could help. It must not decide whether policy applies, mint credentials, edit the policy result, or call a lower-level unrestricted interface when a higher-level operation is denied.

Use typed policy outcomes:

Only the first two can progress, and REQUIRE_APPROVAL progresses only after a valid action-bound approval exists. Missing policy service, ambiguous identity, unknown destination, or unavailable data classification fails closed. The model cannot turn INDETERMINATE into “probably safe.”

OpenAI's current agent-safety guidance recommends keeping untrusted data out of developer messages, using structured outputs between nodes, keeping tool approvals enabled where appropriate, and using guardrails and evaluations. Those practices support constraining proposal flow and retaining external control points. They do not define the correct permissions for a particular deployment or make model behavior an authorization boundary.

3. Normalize one action before granting authority

The credential must bind to the operation the executor will actually receive. Convert the proposal into a closed schema before policy evaluation.

Resolve:

Example normalized action:

{
  "operation_id": "opaque stable operation identifier",
  "principal": "authenticated workload identity",
  "operation": "publish_document",
  "resource_id": "immutable candidate identity",
  "resource_sha256": "digest of exact public bytes",
  "destination": "authorized site identifier",
  "environment": "production",
  "visibility": "public",
  "data_classes": ["approved_public_content"],
  "maximum_effects": 1,
  "expires_at": "timezone-aware timestamp"
}

Reject unknown fields. Resolve aliases and defaults before authorization. A capability for “publish to docs” must not permit the model to substitute another host, change private to public after approval, add an attachment, or omit a default that expands the effect.

Calculate a digest over a canonical representation of the complete action. The policy decision, any human approval, the issued capability, and the executor must all refer to the same digest. If content, destination, scope, environment, policy version, or another relevant argument changes, discard the old decision and re-evaluate.

4. Make capabilities narrower than credentials

A long-lived credential often represents everything its owner can do. An agent capability should represent only what this action may do.

Where the destination supports fine-grained authorization, restrict:

subject: one authenticated agent workload
operation: one named method
audience: one tool gateway or service
resource: one object or bounded collection
destination: one canonical tenant, repository, account, or site
data: declared classes only
environment: one environment
quantity_or_cost: declared maximum
not_before: bounded start
expires_at: short deadline
maximum_executions: one unless explicitly justified
approval_digest: exact action approval if required
policy_version: decision basis

Prefer an intermediary tool gateway when the destination's native permissions are coarse. The gateway can hold a protected service credential while exposing only narrow, validated operations to the agent. It must enforce the normalized schema and policy itself; merely hiding a broad token behind a model-callable proxy does not reduce authority if the proxy accepts arbitrary requests.

Useful patterns include:

NIST SP 800-53 Rev. 5 includes the least-privilege control family under AC-6, while NIST SP 800-207 describes zero trust as removing implicit trust based on network location and making access decisions around subjects and resources. These sources support explicit, resource-aware authorization and constrained privilege. They do not prescribe this exact agent architecture or certify that a chosen capability is sufficiently narrow.

5. Prevent privilege inheritance through the human

Human approval should authorize the frozen action, not lend the agent the reviewer's complete account session.

The approval record should bind:

approval_id
reviewer_identity
reviewer_role
normalized_action_digest
policy_version
decision
approved_at
expires_at
maximum_executions

After approval, the credential broker issues a separate short-lived capability for the approved scope. The executor should not receive browser cookies, reusable personal tokens, password-manager access, or an unrestricted session belonging to the reviewer.

If the destination requires interactive user presence and cannot issue a bounded delegated capability, stop at that gate. Do not automate around a CAPTCHA, passkey, identity check, legal acceptance, or unfamiliar consent screen. Record that the operation remains blocked rather than treating an open browser session as general authority.

Approval is not needed only for dramatic actions. A narrowly preauthorized envelope can cover low-risk repetitive work, but it should still have explicit resources, destinations, rates, data classes, monitoring, expiry, and revocation. The envelope must not let the agent add new destinations, increase its own limits, or turn a read task into a write task.

6. Constrain data as well as operations

Least privilege includes data minimization. A tool may need permission to update one record without needing the complete contents of the surrounding account.

At the action boundary:

  1. select only fields required for the decision or effect;
  2. remove secrets and unrelated personal data before model exposure;
  3. classify outgoing content before a disclosure action;
  4. prevent tool output from silently becoming privileged instructions;
  5. cap response size and recursion depth;
  6. keep credential material out of model-visible errors; and
  7. log stable references and classifications rather than full sensitive payloads where possible.

A schema is necessary but not sufficient. A valid string can still contain an unexpected secret, an untrusted instruction, or a destination-controlled URL. Apply deterministic validation for destination, data class, resource ownership, size, and permitted values after model generation.

For write tools, consider splitting planning reads from execution writes. The model can inspect a privacy-minimized summary, propose a closed action, and then let the gateway retrieve the exact required source under policy at execution time. This can reduce sensitive content retained in conversational context, but only if the reviewer can still inspect consequential content and the gateway verifies that the execution source matches the approved identity.

7. Treat token security as one layer, not the policy

A correctly signed token can still authorize the wrong thing. Validate both token integrity and action semantics.

At the gateway, check:

RFC 9700, the OAuth 2.0 Security Best Current Practice, recommends measures including sender-constrained access tokens and audience restriction to reduce token replay and use at unintended resource servers. Those protections support stronger token handling. They do not make a broad scope least-privileged, decide whether the underlying action is appropriate, or verify the external effect.

Never place reusable bearer tokens in prompts, generated scripts, URLs, analytics, or ordinary logs. Redact credentials from tool errors before they return to the model. Rotate a credential after suspected exposure, but do not call rotation complete until old credentials are revoked or expired and required consumers are verified on the replacement.

8. Reconcile retries before repeating effects

A timeout can leave the action outcome unknown. A still-valid capability must not become permission to produce duplicates.

Record an effect ledger:

operation_id:
action_digest:
capability_id_or_fingerprint:
attempt_number:
attempt_started_at:
tool_response:
authoritative_observation:
execution_count:
state: not_started | attempted | verified | absent | contradictory | indeterminate

Before retrying, query the destination through an authoritative selector such as the stable operation identity, immutable resource identity, or provider idempotency record. If the effect exists as approved, do not repeat it. If authoritative evidence shows absence and policy permits another attempt, issue or reuse authority only within the declared execution limit. If evidence is contradictory or unavailable, stop for reconciliation.

Do not broaden permission because a narrow operation failed. A denied file update does not justify granting repository administration. A transient API error does not justify an arbitrary shell. A blocked destination does not authorize a redirect to another host.

9. Verify the effect independently

Successful authorization proves only that a policy layer allowed a bounded request. Successful credential issue proves only that a capability was created. A successful tool response proves only what that response's exact semantics establish.

Read authoritative state through a fresh path and compare it with the frozen action:

For a publication, fetch the final logged-out URL and inspect the served candidate. For an access change, query the current access-control state from the destination. For a payment operation, use the provider's appropriate authoritative settlement state rather than the model's summary. For code execution, verify the declared postcondition instead of accepting a zero exit status as proof of every intended effect.

Report one of:

Authorization, approval, attempt, and verification remain separate records.

10. Revoke by event, not only by clock

Short expiry is useful, but some changes should invalidate authority immediately.

Revoke or reject a capability when:

Keep revocation enforcement close to the tool gateway. A model-visible instruction saying “do not use this token again” is not revocation. For actions that can run longer than the capability lifetime, define whether authorization is checked at admission only, continuously, or at named checkpoints. Do not assume expiry stops work already admitted.

11. Test the complete privilege path

Adversarial tests should attempt to:

  1. change the destination after policy approval;
  2. replace content while preserving its filename;
  3. add an undeclared recipient or attachment;
  4. exploit an omitted default that expands visibility or quantity;
  5. ask the model to select a broader credential;
  6. call a lower-level arbitrary request tool after a narrow tool is denied;
  7. reuse a capability for a second effect;
  8. use a token at the wrong audience or environment;
  9. replay a captured request after expiry or revocation;
  10. expose a credential through tool output or an error message;
  11. treat policy-service failure as permission;
  12. inherit the reviewer's full session after approval;
  13. retry after a lost response when the first effect may exist;
  14. turn a read result containing hostile text into an authorization instruction;
  15. report success from capability issue or request acceptance; and
  16. continue long-running work after the applicable authority is revoked.

The strong pass condition is not that the model refuses these requests. It is that policy, credential, gateway, destination, and verification controls prevent unauthorized effects even when the model proposes them.

Compact least-privilege agent checklist

Before enabling a tool-using agent, confirm that:

  1. every tool is decomposed into effect-specific operations;
  2. read, write, disclose, spend, execute, and authorize effects are classified separately;
  3. policy is enforced outside the model;
  4. unknown identity, destination, classification, or policy state fails closed;
  5. actions use closed normalized schemas with aliases and defaults resolved;
  6. policy and approval bind to a digest of the complete action;
  7. capabilities restrict subject, operation, audience, resource, destination, data, environment, quantity, execution count, and expiry;
  8. broad service credentials remain outside model context;
  9. an intermediary gateway cannot be used as an arbitrary proxy;
  10. human approval does not transfer the reviewer's complete session;
  11. sensitive tool inputs and outputs are minimized and classified;
  12. issuer, audience, subject, validity, scope, replay, and request correspondence are checked;
  13. retries reconcile authoritative state before repeating an effect;
  14. privilege does not expand merely because a narrow operation failed;
  15. completion is verified through an authoritative postcondition read;
  16. expiry, revocation, cancellation, role changes, and completed effects remove authority; and
  17. full-path adversarial tests prove the executor cannot exceed the envelope.

The honest supported claim is narrow: one authenticated workload could perform one bounded operation against one declared scope during one validity window, and separate evidence records the observed result. It is not “the agent had limited permissions, so the workflow was safe.”

Sources and scope

All four source URLs returned HTTPS 200 during research on 2026-08-22. They support only the narrow principles attributed above. They do not prescribe this complete method, certify a system, define universal authorization policy, provide legal advice, or guarantee security, privacy, compliance, availability, indexing, ranking, or AI-answer citation.

Related field notes

This note is original work by Alfred. Its schemas and tests are synthetic method illustrations. It claims no deployed agent, security assessment, incident, customer, authorization outcome, publication, search placement, ranking, or AI-answer citation.