AI agent access reviews should answer a simple question: does this agent still need the authority it has today?
The word “still” matters. A permission that was reasonable during a pilot can become unnecessary when the task changes. A named owner can move teams. A temporary integration can remain connected after the project ends. An agent can stop running while its credentials remain usable.
In brief: Review agent permissions against the current task, not the original approval. Reconcile declared access with actual entitlements, use operating changes to trigger reassessment and test that removed authority really stops working. An agent inventory is useful, but it is not proof of access control.
This is a focused operating practice within the Agentic AI architecture and governance reading path. The broader Agentic AI control plane explains how authority is enforced. Here, the question is how that authority stays appropriate as the business changes.
This week's signal: identity is moving closer to business events
On 13 October 2026, Workday announced a definitive agreement to acquire C1.ai. Its stated direction is to connect access governance for people and agents to events such as joining, changing roles and leaving.
CRN's reporting on Workday Rising places the agreement alongside a broader set of agent announcements. The important distinction is between registering an agent and governing what it can reach across connected systems.
This is an announced transaction, not a completed acquisition. Workday says it expects the deal to close in its fiscal 2027 fourth quarter, ending 31 January 2027, subject to customary conditions. The proposed integrated capabilities and benefits are forward-looking vendor statements, not independently demonstrated results.
The operational question is useful regardless of the vendor. When an agent's work changes, what event causes its access to change with it?
A quarterly spreadsheet may discover the answer too late for a short-lived task. Conversely, automatic removal without dependency checks can break a legitimate service. Access review needs both timely triggers and an understanding of what the agent actually does.
Write the current authority contract
Start with one agent and describe its permitted work in ordinary business language.
“Support assistant” is not precise enough. “Read order status for authenticated customers and prepare a proposed resolution, without issuing credits” gives reviewers something they can compare with the configuration.
Record the business purpose, accountable owner, technical maintainer and affected customer or internal workflow. Then specify the data it may read, actions it may request, approval conditions and expiry or review date.
Keep business approval separate from technical implementation. A platform team can implement access without being authorised to decide which customer records a workflow should expose.
For agents acting on behalf of a person, establish whether access is delegated for that session or held by a separate workload identity. Do not assume that copying the person's full permissions is necessary or appropriate.
For background agents, make ownership explicit without pretending the agent is an employee. It needs an accountable sponsor and bounded authority, not a human job title used as a substitute for permission design.
The trusted-autonomy lifecycle guide covers this wider ownership model. An access review turns it into a concrete comparison between authorised purpose and configured capability.
Reconcile the inventory with the systems that enforce access
The declared inventory is the starting point, not the final evidence.
Inspect the identity provider, application roles, connector grants, service accounts and tool gateway that implement the permissions. Identify direct grants as well as inherited access through groups or shared credentials.
Trace a meaningful action end to end. An agent may have read-only access to one application but write access through a separate integration. A tool described as “look up customer” may expose a much wider dataset than its name suggests.
Record the evidence source and when it was checked. A review that only confirms the inventory matches itself will not find permission drift.
A compact review record can contain:
- The current task and approving owner.
- Declared permissions and observed entitlements.
- Recent use, where reliable logs exist.
- The decision to retain, narrow, suspend or remove access.
- The implementation result and verification evidence.
Usage is an input, not the whole decision. An infrequently used recovery action may be legitimate. A frequently used permission may be inappropriate. Ask why the access is needed, not only whether it was exercised.
If a shared service account prevents attribution to a specific agent, record that limitation rather than inventing certainty from aggregate logs.
Make scope changes trigger a review
Periodic recertification catches accumulated drift. Event-driven reviews catch changes that should not wait.
Useful triggers include a new tool, a changed task family, an owner leaving, an integration being replaced or a pilot reaching its end date. A move from recommending an action to executing it is a change in authority even if the agent's name stays the same.
Classify the event before deciding the response. A wording correction may not affect access. A new ability to amend customer records does.
Consider an illustrative service workflow. During a returns pilot, an agent can inspect delivery status and prepare a draft message. The team later narrows its role to summarising cases for advisers. If the original write-capable integration remains connected, the agent retains authority that no longer supports its task.
Do not leave this decision to whether the model currently chooses to use the tool. Remove unnecessary capability at the enforcement boundary.
Where automatic changes are possible, define safe failure behaviour. A failed ownership-transfer event should produce an exception for investigation, not a silent assumption that all permissions are correct.
Treat ownership transfer as an explicit decision
An employee leaving does not always mean the service they sponsored should stop. It does mean someone must accept responsibility before unattended authority continues.
Separate two cases. Personal delegated access should follow the relevant person's authorisation and session rules. A continuing business service may need its own identity and a new accountable owner.
Do not solve the second case by preserving a departed employee's credentials. Establish the appropriate service identity, recertify its permissions and confirm who responds when the agent behaves unexpectedly.
An owner change should also review approval routes. A workflow can appear healthy while its high-risk exceptions are being sent to an inactive mailbox.
Record who accepted the transfer, which permissions were reassessed and which unresolved questions remain. If there is no authorised successor, suspend consequential actions and use an agreed fallback rather than allowing ownership to become nominal.
For a small SaaS company, this can be a short checklist rather than a new governance platform. The requirement is a real decision with evidence, not a particular procurement.
Prove revocation at the action boundary
Disabling a scheduler stops new scheduled work. It does not necessarily invalidate credentials already issued or stop a running process from making another request.
Removing a tool from a user interface is also different from removing the underlying grant. Review each enforcement point that matters to the action.
The established OAuth 2.0 token-revocation standard, RFC 7009, illustrates why implementation details matter. It defines a revocation endpoint and distinguishes refresh-token and access-token support. It also recognises propagation delays and differences in how related tokens are invalidated.
Do not assume that revoking one grant instantly cancels every token, session or delegated credential across an integration. Verify the provider's behaviour and your own architecture.
Use a controlled, non-destructive test. After narrowing access, confirm that a permitted read still works and the removed write is denied. Where possible, test through the same tool and identity path that production uses, in a safe test environment.
Keep raw credentials out of evidence. Record identity references, decision outcomes and timestamps, not token values.
For emergency suspension, define how to stop new work, block consequential calls and handle work already in flight. Test the procedure before relying on it during an incident.
Removing access does not reverse completed work
A successful access change prevents or limits future actions. It does not unsend a message or undo a database update that already happened.
Check queued jobs, retries, cached data and downstream approvals separately. A job accepted by another system may continue after the originating agent is disabled.
Decide whether to drain, cancel or manually reconcile outstanding work. Preserve audit evidence according to the applicable retention policy, while removing data the agent no longer needs.
Customer continuity matters here. If an agent was handling a service case, the fallback needs enough context for a person to complete it without repeating unsafe actions.
The Omningage product case study provides context for joined-up service workflows. It is not evidence that the product implements the specific access-review procedure described here.
Ask suppliers to demonstrate the change, not just describe it
During a platform assessment, ask the supplier to show a bounded permission reduction and ownership transfer.
Can it identify the real grants behind an agent's tools? Can it distinguish the person who configured the agent from the person currently accountable for it? What happens to issued credentials, running tasks and approvals when access is removed?
Ask which parts are available now, which depend on another system and which are roadmap items. An agent registry, an identity dashboard and a cross-application revocation mechanism are not interchangeable.
Require evidence proportionate to the consequence. A demonstration with a harmless test resource is more informative than a broad claim that governance is built in.
Keep the results attached to the implementation decision. The technology delivery approach should include these operational acceptance conditions before the rollout expands.
A practical review to run this month
Select one agent with access to a consequential system. Name its owner and write its current authority contract. Reconcile that contract with the actual grants.
Find one permission that should be removed or narrowed, implement the change safely and verify both allowed and denied behaviour. Then test what happens when the owner changes or the task ends.
Record the gaps, assign owners and repeat across the next highest-consequence workflows. Measure unresolved excess permissions and time to implement decisions, not simply the number of agents marked reviewed.
If you need help turning the findings into an implementation plan, discuss an Agentic AI delivery scope.
Access control is not finished when permission is granted. It remains dependable only when the organisation can explain why the permission still exists and prove that it can remove it.
Sources and evidence notes
- Workday acquisition announcement, 13 October 2026. Primary vendor release. The transaction is an agreement subject to closing conditions; proposed integration benefits are forward-looking.
- CRN, Workday Launches AI Agent Deluge, Acquires Agentic Identity Startup, Rick Whiting, 13 October 2026. Technology reporting on the same announcements, not independent proof of the proposed controls.
- RFC 7009, OAuth 2.0 Token Revocation, August 2013. Established protocol reference, not a new agent-specific standard. Actual provider and resource-server behaviour must be verified.
Sources checked on 19 October 2026. The review procedure and service example are original recommendations, not claims about deployments or measured outcomes in Ahmad Nizami's businesses.