The AI Agent
Access Readiness Assessment
Can you prove your agents should have access?
- 01Identity and issuance
- 02Delegated authority and scope
- 03Revocation and containment
- 04Audit and cross domain trust
before production
Introduction
Before an agent is deployed in production
An AI agent may perform well in a pilot but risk functions will halt deployment to production. Which systems will it be able to reach? Who has authorised it to act? If something goes wrong, how quickly can you withdraw its access?
These questions need clear answers before an agent can work with client records or carry out transactions. This assessment helps architecture, security and AI product managers work through them together, identify gaps and agree what needs to happen next.
We have kept it to sixteen questions, covering identity, delegated authority, revocation and audit evidence. It focuses on access, one part of the wider work involved in governing AI agents.
Why existing credentials deserve a closer look
In our 2025 API security research, which covered 68 organisations, about 84% relied on bare API keys or basic shared secrets for API authentication.1 If an agent uses one of those credentials, it inherits the access attached to it. Where several workloads share the credential, the API may not be able to tell which one made a request.
A worked example
When an agent replaces an application
A relationship manager preparing a client review would once have used an application built for the purpose. The application called a known set of APIs in a fixed order, and every call could be attributed to it.
An agent doing the same job is useful because it is not fixed. It can gather wider context, reach systems the application never touched, and pass work to other agents. Each of those systems sees the agent or tool that called it, rather than the person who asked for the review.
The questions that follow help you check whether that information is available when access is granted, and whether you can reconstruct it afterwards.
How to use it
How to use this assessment
Before you score, choose the agent or service you are assessing and agree which environments and integrations are in scope.
- 01
Assess current controls
Score what is working today. If a control is planned but has not been implemented, record it as a next step. For agents still in a sandbox, use this as a design review and keep planned controls separate from tested ones.
- 02
Choose the answer you can support
Each question scores 0, 1 or 2. If your position falls between two answers, use the lower score and note what is missing. If you do not know, record 0 until you have checked.
- 03
Compare answers before agreeing a score
Ask architecture, security and the agent owner to complete the questions separately. Discuss any differences, especially a 0 from one team and a 2 from another. The aim is to agree what the evidence shows.
- 04
Keep a note of the evidence
A configuration, access record or test result is more useful than an assumption. Record anything you need to verify, who will check it and by when.
The four sections
Identity and issuance
How agents are identified, who owns them and how credentials are managed.
Delegated authority and scope
Whose authority an agent uses and how its permissions are limited.
Revocation and containment
How you withdraw access and limit the impact of a compromised agent.
Audit and cross domain trust
What you can evidence, including when agents work across organisational boundaries.
Identity and issuance
Complete this section with platform engineering and identity and access management teams.
Start with how your systems recognise the agent. A shared account can make it harder to set permissions for one agent, withdraw its access independently or establish which workload made a call.
Q1
When an AI agent calls an internal API, what identity does it present?
Joint guidance from the Five Eyes cyber security agencies recommends a distinct cryptographic identity for each agent, with its own keys or certificates. This gives your systems a way to distinguish one agent from another.2
Q2
Who issues agent identities, and is ownership recorded?
A named owner gives you someone to contact when access needs reviewing, the agent changes purpose or it is retired.
Q3
Do you know which agents hold credentials for production systems?
Check the inventory against credentials and access records. A list of approved projects may miss agents that have been added, changed or left running.
Q4
How are agent credentials renewed?
Short lifetimes reduce the window for misuse. Separately, check how tokens are protected: certificate-bound access tokens require proof of the corresponding private key. A certificate alone does not provide that protection.3
Section 1 score
Pick an answer for each question · 0 of 4 answered
Q5
When an agent acts for a person, can the relying system check whose authority it carries?
A log helps you investigate later. An access decision needs trusted information at the time of the request, whether it arrives with the token or is resolved from a trusted source.
Q6
When an agent delegates work to another agent, how are permissions limited?
An agent asked to retrieve a balance should not inherit permission to make a payment. The delegation analysis published by the Cloud Security Alliance identifies missing scope restrictions as a key weakness.4
Q7
How specific are the permissions an agent holds?
For example, permission can be limited to reading a particular account for a defined period. OAuth Rich Authorization Requests provides a way to describe detailed access requirements; your systems must still enforce the permissions granted.5
Q8
Can the relying system verify how authority was delegated?
A valid token can prove that a trusted issuer made an assertion. It does not necessarily contain evidence of every delegation along the way. Check what your relying systems can actually verify.6
Section 2 score
Pick an answer for each question · 0 of 4 answered
Revocation and containment
Complete this section with security operations, incident response and identity and access management teams.
If an agent acts outside its remit, you need to know how to withdraw its access and what happens to work it has already delegated.
Q9
How quickly can you stop an agent from making further authorised calls?
Measure the delay at the relying systems. Where authority is published and resolved rather than registered locally, a change made once at the source reaches each system when the answer it holds expires. Record how long your systems hold an answer, and how long issued tokens remain valid.
Q10
Does withdrawing an agent's authority also withdraw access delegated under it?
Follow the grants created by the original delegation. Downstream agents may have other, independently authorised work; the test is whether they can continue using the authority you withdrew.
Q11
If one agent were compromised, do you know which systems and data it could reach?
Include tools and downstream agents in the review. This gives incident responders a starting point for deciding what to contain and investigate.
Q12
What happens when the person who authorised an agent leaves or their permissions change?
Check existing grants and tokens as well as future requests. A change in the user directory only helps if the systems relying on that authority respond to it.
Section 3 score
Pick an answer for each question · 0 of 4 answered
Audit and cross domain trust
Complete this section with risk, compliance and architecture teams.
Can you show what an agent did, and under whose authority, inside your own systems and beyond them? Where another organisation is involved, both sides need an agreed way to check identity and authority.
Q13
Could you show who authorised an agent action and which permissions applied at the time?
Use a real action as a test. Ask someone who did not build the agent to follow the evidence from authorisation through to the API call.
Q14
How do your systems verify an agent from another organisation?
A separate arrangement can provide strong checks. The question is whether those checks remain manageable as more partners join, and whether a change made by the other side reaches your systems. A published trust framework lets a platform admit an agent it holds no record of, by resolving its authority rather than registering it in advance.
Q15
Are these access controls applied consistently across the boundaries your agents cross?
Choose a workflow that crosses a boundary and follow it through. Check whether both sides can verify authority, apply the intended restrictions and respond when access is withdrawn.
Q16
Can you identify the running instance that made a call?
Several copies of an approved agent may be running at once, in different environments. Workload identity standards such as SPIFFE give a running instance something it can prove about itself, which can then be used to set a ceiling on what that instance is allowed to do.
Section 4 score
Pick an answer for each question · 0 of 4 answered
Scoring
What your score means
- 1Identity and issuance/ 8
- 2Delegated authority and scope/ 8
- 3Revocation and containment/ 8
- 4Audit and cross domain trust/ 8
Pick an answer for each question and your scores add up here. Or download the PDF and score it by hand.
Several access controls are missing or you cannot yet evidence them. Review the agent's access before expanding its use, especially where it can reach sensitive data or take actions with financial consequences.
Where to start
Start with an inventory, named owners and separate agent identities. Identify any access that needs restricting while the remaining controls are put in place.
Some controls are in place, but coverage or evidence is incomplete. Use the lowest-scoring questions to decide where to work next. Check delegation and revocation carefully if the agent passes work to other agents or tools.
Where to start
For each gap, agree an owner, a target date and a test that will show whether the change works.
Your answers suggest that many of the access controls are in place. Check the evidence behind the score, address any remaining zeros and test the controls across the full workflow, including partner systems where relevant.
Where to start
Keep the assessment current as the agent's tools, permissions and integrations change.
Use the bands as a guide. These are Raidiam's suggested review bands, not a validated industry benchmark or a production approval. Your decision should reflect the use case, the evidence and your bank's risk requirements.
Next steps
What to do next
- 1
Identify and document existing agents and production access
Bring together project lists, identity records and production credentials. Record an owner for each agent and the systems it can reach. Follow up on entries that do not match.
- 2
Give each agent a managed identity
Replace shared credentials with identities you can manage separately. Agree how they are issued, renewed, reviewed and retired, and who is responsible for each step.
- 3
Agree when a person must approve
Define which actions the agent may take on its own and which require approval. Use criteria your systems can enforce, such as transaction value, data sensitivity or the effect on a customer. Test that actions requiring approval cannot bypass it.
- 4
Run a revocation test
In a controlled test environment, withdraw an agent's authority and measure how long further calls remain possible. Include existing tokens, downstream grants and queued work. Record what continues and compare the result with your incident response target.
- 5
Choose how you will establish trust with partners
Decide how external agents will prove their identity and authority, and how changes will be communicated. Consider the effort of maintaining separate arrangements as the number of partners grows.
About Raidiam
Where Raidiam fits
Raidiam Connect holds the record for an agent: its own federation identifier and keys, the operator that stands behind it, and the authority it has been given. Your platform resolves that record through OpenID Federation, back to an anchor it pins itself.
Your systems continue to make and enforce the access decision, applying your own policy to every agent they admit. A platform can admit an agent it holds no record of by resolving its authority, rather than registering it in advance, and it reads a change at the source when the answer it holds expires. The model is built on OpenID Federation 1.0, OAuth 2.0, X.509 and mTLS, with SPIFFE for workload identity. Raidiam runs this infrastructure in regulated ecosystems today.
Proven where trust is regulated.
2bn
API calls a week
99.99%
Production uptime
Eight
National trust frameworks
Thousands
Regulated participants
Discuss the results with Raidiam
Bring your assessment, including any sections you could not complete. Thirty minutes, no slides, with someone who runs this day to day, and a straight answer on what to do next.
References
The sources below support the technical explanations in this guide. The assessment questions and scoring bands are Raidiam's own.
- [1]
The API Security Gap: Why Most Enterprises Are Still Vulnerable
Raidiam, 25 June 2025. Public summary of the 2025 API security research, including the 68-organisation sample and approximate 84% figure.
raidiam.com/insights/the-api-security-gap-why-most-enterprises-are-still-vulnerable - [2]
Careful adoption of agentic AI services
Joint guidance from the Five Eyes cyber security agencies, 1 May 2026. Available from the Australian Cyber Security Centre.
cyber.gov.au/business-government/secure-design/artificial-intelligence/careful-adoption-of-agentic-ai-services - [3]
OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
IETF RFC 8705.
rfc-editor.org/rfc/rfc8705.html - [4]
Control the Chain, Secure the System: Fixing AI Agent Delegation
Kundan Kolhe, published by the Cloud Security Alliance, 25 March 2026; originally published by Okta.
cloudsecurityalliance.org/blog/2026/03/25/control-the-chain-secure-the-system-fixing-ai-agent-delegation - [5]
- [6]
FAPI 2.0 Security Profile
OpenID Foundation. Further reading on API security; this specification does not define the assessment score.
openid.net/specs/fapi-security-profile-2_0-final.html
Read the full assessment
Get all sixteen questions, the scoring bands and five practical next steps. It opens as soon as you submit, with the PDF to download.
Get the assessmentWhere will your ecosystem take you?
Whether you're a regulator building a national digital economy, an enterprise platformising across brands and clouds, or a bank that wants to stop rebuilding trust for every new use case, there's a next step.
See It in Action
See how one investment in Raidiam Connect covers your first use case, and the next hundred.
See the Proof
Explore how governments, regulators and enterprises are using Raidiam to deliver trusted digital ecosystems.
Have questions first?
Tell us about your ecosystem and we'll show you where Raidiam fits.