What is agent access readiness?

Agent access readiness is the degree to which your AI agents operate under controls that were deliberately designed for agentic execution — not inherited from human IAM. It covers two tracks: design-time controls (inventory, ownership, policy, tool surface) and execution-time controls (credential scope, per-action authorization, blast radius limits, and audit evidence). A team is not ready to run agents in production until both tracks are sufficiently covered.

Why does login-time identity not cover agent actions?

Login-time identity authenticates a person at the moment they enter a system. It says nothing about what that person's agent is allowed to do twenty tool calls later, in a chain the person never explicitly reviewed. Agents inherit standing permissions and static credentials, which means every action the agent takes is implicitly authorized by the original login — regardless of whether the action fits the task, the scope, or the risk tolerance for that moment. Runtime access control evaluates each action independently, at the moment it executes, against the intent of the triggering request.

What counts as an execution-time control?

An execution-time control evaluates a specific action before it completes. Examples include: a policy check that compares a tool call against the originating task intent; a credential system that issues task-scoped tokens that expire when the run ends; a rate limit that caps state-changing calls per execution; and an action-level log that records the allow-or-deny decision for each tool call. A log that records what happened after the fact is an observation mechanism, not a control — it cannot stop an action that has already completed.

How long does this assessment take?

About ten to fifteen minutes for a single person who knows their stack. The gate questions take under a minute. Each of the eighteen checklist items is a single yes, partial, or no answer. If you need to look up credential provisioning details or check audit log coverage, allow additional time. Answers are saved in your browser as you go, so you can close the tab and return without losing progress.

What happens to my answers?

Your answers are stored only in your browser. They are written to localStorage under the key agntid-assessment-v1 and encoded into the URL fragment when you share a link. No answer data is sent to AgntID or any server unless you submit the Access Scanner form, at which point only the information you explicitly enter in that form is transmitted.

Security checklist

Agent Access Readiness

18 control questions across 8 categories. Track A covers design-time decisions: agent inventory, ownership, policy, and tool surface. Track B covers execution-time behavior: credential scope, authorization, blast radius, and audit evidence. Answers are scored, gaps are ranked by severity, and results persist in your browser.

18 questions8 categories2 tracksAnswers saved locally

Your answers stay in your browser. They are written to localStorage and encoded into the URL fragment when you copy a share link. No answer data reaches any server unless you submit the Access Scanner request form, at which point only the information you enter in that form is transmitted.

Gate questions

Do your AI agents call tools or APIs rather than only returning text?
Can an agent write, update, or delete data in a system you care about?
Does an agent reach production, customer data, code repos, cloud infra, CRM, finance, or HR systems?

Agent and tool inventory

Can you produce a complete list of agents running today, each with a named human owner?
An agent can be deployed, modified, or abandoned with no record, leaving ownership gaps that surface only after an incident.
Glossary: No agent inventory
Can you show which tools and MCP servers each agent reaches, which actions write or delete, and which can touch production, in minutes?
Security cannot assess blast radius before approving a rollout, and a newly connected tool reaches production before it is reviewed.

Ownership and delegation trail

Can you name the accountable human and the user request behind each agent action, linked at the time of the call?
When an agent causes data loss or an unauthorized change, you cannot reconstruct which person initiated the chain or which request authorised it — the audit trail ends at the agent identity.
Glossary: Missing accountability trail
Do agents stop carrying access once the task ends, separate from what their host workload is allowed to do?
Credentials or permissions acquired for a single task remain active indefinitely, expanding the window for abuse or accidental misuse by subsequent runs.
Glossary: Persistent over-provisioned access

Policy management

Do policies live in one place rather than in agent code, so a change takes effect without redeploying, versioned, auditable, with time-bound exceptions?
An emergency policy change requires a code deploy, delaying response during an active incident, and no canonical record of what the policy was at any point in time.
Do engineering and security work from the same policy rather than two sets of rules?
The rules enforced at runtime differ from what security believes is in place, so audits and threat models are based on a policy that does not match production behaviour.

Tool surface, incident readiness, and compliance

Do you know which MCP servers are connected, can you retire a tool from every agent at once, and does security see a new tool before an agent calls it?
A new or third-party MCP server is called in production before security has reviewed it, and removing a compromised tool requires locating and patching every agent individually.
Can you reconstruct every action an agent took in an incident window, tell agent from person, and revoke access mid-run, without custom scripts?
Incident response stalls while engineers write ad-hoc log queries; access cannot be revoked until the current run completes, extending the exposure window.
Can security approve a rollout and prove least privilege to an auditor, backed by evidence for customer questionnaires and SOC 2 or ISO?
Security approvals are verbal or undocumented, and the organisation cannot produce machine-readable evidence during a SOC 2 audit or a customer security review.

Credential scope for agents

Do agents hold task-scoped, short-lived credentials rather than shared service accounts or static keys?
A compromised agent or leaked key grants indefinite access across every system that credential reaches, with no natural expiry to limit the window.
Glossary: Static or shared credentials
Can you tell which agent used which credential for a specific action, with different jobs carrying different access?
Multiple agents share an identity, so a destructive action cannot be attributed to a specific run, making post-incident root cause analysis impossible.

Execution-time authorization

Is every tool call evaluated against task intent or deterministic policy before execution?
An agent can call any tool its credentials allow regardless of whether the action fits the originating task, removing the last programmatic check before a write or delete.
Glossary: Unevaluated tool calls
When intent is unclear, can policy allow, deny, narrow, or require approval, using the tool, parameters, target, and task context?
Ambiguous calls are either blocked entirely — halting legitimate work — or pass unchecked, with no mechanism to constrain scope or escalate for human review.
Can one action be blocked or constrained inline without disabling the agent or ending the workflow?
Blocking a single risky action kills the entire run, so operators accept the risk rather than disrupt the workflow — enforcement becomes optional in practice.

Blast radius and irreversible actions

Do you know which actions are irreversible, and do they face a tighter per-action check than read actions?
Deletes, overwrites, and financial transactions are evaluated by the same policy as read calls — an agent can cause unrecoverable damage with no additional friction.
Glossary: No irreversibility classification
Is there a ceiling on state-changing calls per run, and can you cut off one tool for one agent without a code deploy?
A runaway agent or prompt-injected loop can write or delete without bound, and the only mitigation is a code deploy that takes it offline entirely.

Action-level audit evidence

Does every tool call log the agent, tool, action, parameters, and allow or deny decision, consistently across cloud, Kubernetes, databases, and SaaS?
Some tool calls produce no log entry at all, and those that do log inconsistently — different fields, formats, or verbosity — making cross-system correlation unreliable.
Can an auditor trace one changed record back to the agent run, with logs reaching your SIEM in a standard shape?
A changed or deleted record cannot be traced to the agent run, user request, or policy decision that caused it — forensics require manual log correlation across disparate systems.

Scope check

Three questions to calibrate the checklist to your deployment

Answers here are not scored. They determine which controls apply and how severity is weighted.

1.Do your AI agents call tools or APIs rather than only returning text?

YesPartialNo

2.Can an agent write, update, or delete data in a system you care about?

YesPartialNo

3.Does an agent reach production, customer data, code repos, cloud infra, CRM, finance, or HR systems?

YesPartialNo

Answer all three questions to continue.

Frequently asked questions

What is agent access readiness?: Agent access readiness is the degree to which your AI agents operate under controls that were deliberately designed for agentic execution — not inherited from human IAM. It covers two tracks: design-time controls (inventory, ownership, policy, tool surface) and execution-time controls (credential scope, per-action authorization, blast radius limits, and audit evidence). A team is not ready to run agents in production until both tracks are sufficiently covered.
Why does login-time identity not cover agent actions?: Login-time identity authenticates a person at the moment they enter a system. It says nothing about what that person's agent is allowed to do twenty tool calls later, in a chain the person never explicitly reviewed. Agents inherit standing permissions and static credentials, which means every action the agent takes is implicitly authorized by the original login — regardless of whether the action fits the task, the scope, or the risk tolerance for that moment. Runtime access control evaluates each action independently, at the moment it executes, against the intent of the triggering request.
What counts as an execution-time control?: An execution-time control evaluates a specific action before it completes. Examples include: a policy check that compares a tool call against the originating task intent; a credential system that issues task-scoped tokens that expire when the run ends; a rate limit that caps state-changing calls per execution; and an action-level log that records the allow-or-deny decision for each tool call. A log that records what happened after the fact is an observation mechanism, not a control — it cannot stop an action that has already completed.
How long does this assessment take?: About ten to fifteen minutes for a single person who knows their stack. The gate questions take under a minute. Each of the eighteen checklist items is a single yes, partial, or no answer. If you need to look up credential provisioning details or check audit log coverage, allow additional time. Answers are saved in your browser as you go, so you can close the tab and return without losing progress.
What happens to my answers?: Your answers are stored only in your browser. They are written to localStorage under the key agntid-assessment-v1 and encoded into the URL fragment when you share a link. No answer data is sent to AgntID or any server unless you submit the Access Scanner form, at which point only the information you explicitly enter in that form is transmitted.