This checklist groups the access control questions worth answering before an AI agent goes anywhere near production, and revisiting periodically once it's there. It's organized around five areas that tend to fail independently of each other: identity, permission scoping, approval workflows, credential lifecycle, and emergency preparedness. An agent can score well on one area and still carry serious risk in another, a well-scoped agent with no kill switch, or a properly gated agent whose service account was never rotated, so treat this as five separate reviews rather than one pass-fail judgment. None of these items require exotic tooling; most come down to whether a decision was made deliberately or defaulted into because it was the fastest way to get something working.

Identity foundations

Get these right first, because almost everything else in this checklist depends on identity being trustworthy and distinct.

  1. Give the agent its own distinct identity, separate from any user it acts for, so its actions can be tracked and revoked independently.
  2. Propagate the originating user's identity through every hop the request makes, rather than collapsing to a single service credential.
  3. Distinguish user identity from agent identity clearly in every log entry and authorization check.
  4. Use workload identity or short-lived credentials for the agent's runtime authentication instead of static, long-lived secrets.
  5. Assign a named owner responsible for each agent identity and its permissions.

Scoping and permission design

Scope reflects intent. If the scope is wrong, every downstream control is protecting the wrong boundary.

  1. Build the agent's permission set from its actual task requirements, not a framework's default role.
  2. Separate read access from write access, defaulting to read-only unless write is specifically justified.
  3. Review what the agent's full set of permissions could accomplish combined, not only individually.
  4. Enforce spending, transaction, and rate limits outside the model, where a prompt can't argue past them.
  5. Re-scope the full permission set when the agent's task or responsibilities change, not just add to it.

Approval and human oversight

Decide deliberately which actions need a human involved before execution, and which can proceed under monitoring instead.

  1. Require approval for actions that are irreversible, above a defined impact threshold, or outside the agent's normal pattern.
  2. Route approval requests to someone with the context and authority to actually evaluate them.
  3. Default to deny, not allow, when an approval request times out without a response.
  4. Keep the agent proposing an action distinct from whoever approves it, especially for high-value actions.
  5. Monitor approval and denial rates, and investigate if denials trend toward zero.

Credential and access lifecycle

Access that never expires is access nobody is actively managing, and that's exactly the access most likely to be misused eventually.

  1. Use time-bound or just-in-time provisioning instead of standing access wherever the task allows it.
  2. Rotate static service account credentials on a defined schedule.
  3. Ensure revocation takes effect at the next request, not the next scheduled refresh cycle.
  4. Test revocation directly by attempting an action with old credentials afterward.
  5. Disable an agent's service account and delegated tokens as part of its retirement, not as an afterthought.

Monitoring, audit, and emergency readiness

When something does go wrong, the speed of your response depends entirely on preparation you did before the incident, not during it.

  1. Record the user, agent identity, policy decision, and approval outcome for every meaningful action.
  2. Make audit records append-only and restrict who can modify them after the fact.
  3. Build a kill switch that revokes credentials and halts scheduled tasks, not just disables an interface.
  4. Test the kill switch periodically to confirm it actually stops every path the agent can act through.
  5. Define a deliberate review and recovery process before re-enabling an agent that was stopped.

Where TELEON fits

TELEON is positioned as a gateway between agents and the model providers or tools they call, enforcing policy at the tool-call boundary and recording an audit trail of that activity. That makes it a natural place to implement several items on this list: holding actions pending approval, applying transaction limits consistently, and providing the record needed to verify revocation or investigate an incident. It also supports privacy vault tokenization for sensitive values that would otherwise need to reach a model's context, and trust scoring that can feed into monitoring for unusual agent behavior.

TELEON doesn't decide what an agent's permissions should be, design the approval workflow's routing logic, or build the credential rotation schedule; those decisions and that infrastructure work still belong to the team operating the agent. What it does is give those decisions somewhere consistent to be enforced and recorded, across agents built on different frameworks or pointed at different model providers.

Most of the items on this checklist aren't difficult individually. What makes agent access control hard in practice is that these five areas get built by different people at different times, often under deadline pressure, and nobody ever steps back to check whether they still hold together as a whole. Running through a checklist like this one periodically, not just once before launch, is usually what catches the gap between what the architecture diagram says and what the system is actually doing.