Before You Let an Agent Log In: A Review Checklist

An agent tool access review is the structured set of questions to settle before an autonomous agent gets standing access to your business systems. The reason it needs writing down now is simple — agents no longer arrive only through API contracts with scoped keys. They arrive with a browser and a desktop, and they sign into tools that have no API at all, exactly the way a new employee would.

That shift breaks the assumptions your existing vendor review was built on. An API integration has a key you can rotate, scopes you can enumerate, and a revocation endpoint. A browser session on a cloud desktop has cookies, saved logins, and files — and those can outlive the agent that created them. The review has to change shape accordingly.

This guide builds a nine-question, buyer-side review checklist and tests it against a rare artifact: a frontier vendor's fairly complete, self-contained, published security and approvals model — the documentation xAI shipped for Grok Bot, its autonomous-agent product, in beta at the time of writing. We use it as the worked example not to praise or criticize the product, but because it is specific enough to be checkable point-by-point — which is exactly what you want from any vendor you review.

The current generation of agent products is explicitly built to work where APIs end. xAI's Grok Bot — marketed as AI teammates you can give real work to — launched in beta on August 11, 2026 for SuperGrok Heavy, Cursor Ultra, and Cursor Teams Premium subscribers (xAI's own pages also render that last tier as Cursor Premium Teams), on macOS, Windows, and iPhone. Each bot works on a cloud computer with a real browser, real files, and real logins. We cover the launch itself in a companion piece on Grok Bot's cloud-computer model; this post is about the decision that comes before any of that — whether and how to grant access at all.

The interesting thing about this particular product, for a reviewer, is the documentation. xAI published an approvals, security, and privacy page plus an FAQ that together describe the access model in unusually concrete terms: where credentials live, what deletion removes, who completes sensitive steps, what the approval engine can and cannot do. That gives a buyer exactly what a checklist needs — a set of specific, falsifiable statements to run it against. Every vendor claim quoted in this post comes from those two pages as published at the time of writing.

One framing note before the checklist: nothing here is an attack analysis. The questions below are the ones a competent reviewer asks about any system that holds standing access — the same questions your auditors already ask about service accounts and shared mailboxes. Agents just make the answers matter sooner, because an agent can request, use, and accumulate access at a pace no human onboarding process ever did.

The single most load-bearing fact in the worked example is architectural. The docs state: "All of your Bots share one cloud computer assigned to your user account. Files, browser sessions, and command line credentials on that computer are available across your Bot roster." The FAQ answers the follow-up directly — every bot on the account uses one persistent cloud computer, and they share its files, browser sessions, and logins so they can hand work off.

To the vendor's credit, the docs draw the security conclusion themselves, and repeat it on both pages we reviewed:

The buyer-side implication — our analysis, not the vendor's — is what your review must extract from any agent platform's docs before a multi-agent rollout: if the vendor issues one shared session and credential surface per account rather than per named agent, then "agent A has scope X, agent B has scope Y" does not create the separation you might assume. Five agents with five different task descriptions can still be one blast radius, because a login saved by one is reachable by all. That is not necessarily disqualifying — a single-owner account with low-stakes tools may not care — but it must be a known fact, not a discovered one.

This is also where naming architecture honestly matters when you compare vendors. A platform that gives each agent its own isolated identity — its own credentials, its own sessions, its own audit trail — is making a structurally different offer than one shared computer with several personas on it. We covered the per-agent identity pattern in depth in our playbook on giving agents their own identity; the review question here is simply which of the two models the vendor in front of you actually runs.

The second load-bearing fact follows from the first. The docs state: "Deleting a Bot does not remove shared-computer files or browser sessions." The FAQ repeats it — because bots share a computer, files and logins on that computer may remain after a bot is deleted, and backend retention follows the applicable Cursor terms. The agent object and the access it used are separate things with separate lifecycles.

A reviewer should treat this as the general case until a vendor proves otherwise. "We deleted the agent" and "we revoked its access" are different claims, and offboarding has to verify both: the agent is gone, and every session, cookie, and stored credential it could reach is separately terminated. This is not a novel insight — OWASP's Non-Human Identities Top 10 puts improper offboarding at the top of its 2025 list — but agents make the gap wider, because a browser-driving agent accumulates sessions in places no offboarding script is watching.

What distinguishes the worked example is that the vendor publishes an explicit, ordered removal sequence: pause or delete related routines; sign out of websites on the shared computer; uninstall connectors and revoke their authorization in the source service; remove sensitive project files from the workspace; hide or delete the bots themselves; and use the account-settings flow for full account deletion. Whether a vendor publishes such a runbook at all is itself a checklist row — this one does, and that is a fact about this vendor, not the category.

The strongest pattern in the worked example is the one most worth demanding from every vendor: the human keeps the credentials. For sensitive steps, the docs state: "For passwords, passkeys, two-factor codes, CAPTCHAs, and payment confirmations, the Bot should hand you control of the computer." The documented flow is a take-control handoff — open the agent's computer, take control, complete the sensitive step yourself, return control, and tell the agent to continue. The docs are equally blunt about the anti-pattern: "Do not send a password or one-time code in ordinary chat."

A take-control handoff is materially different from "the agent authenticates via OAuth" or "the agent stores your password." Neither of those mechanisms appears on the two policy pages we reviewed — the model, as documented, is that the human performs the authentication moment and the agent inherits the resulting session on its computer. Which loops back to section 02: the session that authentication creates persists on the shared computer, so the handoff protects the secret itself, not the access that follows from it.

Two review notes sharpen this section. First, the masked secret-request channel is explicitly scoped: it exists for supported connections, is masked in the UI, excluded from the transcript record, and not shown to the model — three properties worth demanding verbatim from any vendor — but the docs do not claim it covers every integration, and neither should your review. Second, execution on the buyer's local computer is a separate control with a documented default: "The default is Ask every time." Note the scope, though — that setting governs the local machine, and it does not narrow what the agent can do on its own cloud computer.

If you want the credential architecture done at the tooling layer rather than by protocol discipline, pair this section with our reviews of 1Password's credential-safe agentic browsing integration and our secrets-management and key-rotation reference — the same principle, human-controlled secrets with masked injection, expressed as products and pipelines.

The worked example's approval model has two properties every reviewer should test for. The first is an explicit boundary list. The docs recommend setting boundaries in the request for exactly the action classes a business would name in any delegation-of-authority policy: sending messages or invitations, publishing content, purchases and financial transfers, deleting or overwriting data, changing permissions, production changes, and accepting legal terms. Seven classes, all side-effectful, all gated before execution rather than reviewed after.

The second property is a sentence that deserves to be framed: "An approval controls the proposed action. It does not reverse work already completed." Approval gates are preventive controls. Your review should map, for your actual workflow, which actions are stopped before they run versus merely logged after they ran — because the second category is where irreversible mistakes live. A useful discipline when scoping the first workflows: the vendor's own least-privilege guidance says to connect only the tools a workflow needs, start with read-only tasks and draft outputs, and keep sending, publishing, purchasing, deletion, and production changes behind approval. That ordering — read-only first, side effects gated — matches how we sequence delegation in our companion piece on what to delegate to an AI teammate first.

Then there is the automated layer. When Auto Review enforcement is available, the docs say, Grok Bot evaluates tool calls and computer actions before they run; Require Approval rules always stop matching actions, and Always Allow rules let actions proceed only when the automated review does not find another reason to stop — with Require Approval winning whenever both match. That precedence order is sensible. What is more instructive is the vendor's own caveat about the whole mechanism.

A tempting mistake is to treat agent access as a brand-new control domain waiting for a brand-new standard. The existing frameworks already reach it. NIST SP 800-53 Rev 5's AC-6 control directs organizations to employ least privilege, allowing only the authorized access necessary for assigned tasks — and it applies that principle not just to users but to processes acting on their behalf, with supplemental guidance extending it explicitly to system processes. That language predates the current agent wave by years; an autonomous agent is precisely a process acting on behalf of a user, just one that can now request access at a pace and breadth no human ever could. Enhancements in the same family restrict privileged accounts to defined roles and prevent non-privileged users from executing privileged functions. (We are paraphrasing the control text here rather than quoting it, and working from a widely used Rev 5 control mirror — precision-critical readers should pull the NIST source directly.)

CIS Controls v8 makes the same reach from the operational side. Control 6, Access Control Management, covers the processes and tooling for creating, assigning, managing, and revoking credentials and privileges — for user, administrator, and, notably, service accounts — and calls for an up-to-date inventory of administrative accounts with documented purpose, regular privilege review, and role-based access control. That is a paraphrase too: parts of the full v8 control text sit behind registration, so this rests on convergent summaries rather than one quotable primary. None of it was written about AI agents specifically, and it does not need to be: an agent's standing access is a service account with a much faster request loop. OWASP's Non-Human Identities Top 10 then names the failure modes — improper offboarding, secret leakage, overprivileged identities, long-lived secrets, identity reuse — that the two control frameworks exist to prevent.

One scoping note: OWASP ranks its NHI list on exploitability, prevalence, detectability, and impact — by its own stated methodology — and it is one respected organization's framework, not a universal taxonomy. Use it as a vocabulary for failure modes, not as a compliance regime. If your question is the broader one — how agent access fits into an organization-wide governance posture, EU AI Act obligations and all — that is a different altitude from this vendor-facing checklist, and we covered it separately in our agent governance framework guide.

Much of an agent's access will still flow through OAuth — the connectors, not the browser — and there the review discipline is older and better documented. Google's published OAuth 2.0 best practices, widely treated as a de facto reference because Google sits on both sides of the protocol, say to "select the smallest, most limited scopes possible" and to request additional scopes incrementally, when the functionality actually needs them, rather than everything upfront at first authorization. Credentials belong in secure storage such as a secret manager — never hardcoded, never committed to a repository. And tokens should be revoked as soon as they are no longer needed, then deleted from your systems.

Two agent-specific applications of that guidance. First, for automated and backend workflows, Google's guidance points toward service accounts rather than standard user-delegated OAuth — so a key checklist question is whether the vendor supports scoped service accounts per integration, or only a broad grant against a person's own account. An agent riding its owner's personal OAuth grant inherits everything that person can touch; a scoped service account inherits only what the task needs, and its removal is clean. Second, on revocation: the OAuth ecosystem has a dedicated standard for token revocation, RFC 7009, and the widely repeated guidance in identity-security practice is that refresh tokens should rotate, reuse of a rotated token should be treated as compromise, and revocation should invalidate the whole token family rather than the single presented token. We state that as well-corroborated practice guidance rather than quoted standard text — and the operational takeaway for a reviewer survives either way: ask the vendor to demonstrate revocation, not just describe it. Grant access, revoke it, and verify the agent's next attempt fails.

Everything above compresses into nine questions. Each row names the question to put to the vendor, what a strong answer looks like, the failure signal that should stop the rollout until resolved, and where the question anchors — in the worked example's own documentation or in the frameworks from section 06. Run it as written for any agent platform that wants standing access.

Treat a vendor's own least-privilege guidance as a floor, not a guarantee. Every framework in section 06 converges on the same idea — scope to what the task needs — but none of them can verify an implementation from the outside. That verification is the reviewer's job: confirm the controls are actually configurable, actually enforced, and actually produce the log entries the docs promise. If you want a second team on that verification — running this checklist against a specific vendor, wiring the approval boundaries into your rollout, or building the offboarding runbook your auditors will ask for — that is the kind of engagement our AI transformation practice runs before any agent touches production access.