A data owner approves access for a month-end investigation. The investigation closes. The access stays. Nobody decided it should stay; nobody decided it should go. In October, an AI agent working on behalf of the same person can still reach the data, because the permission it inherited never expired.

This is not a new problem. Access reviews exist because permissions drift: people move roles, projects end, temporary grants become permanent through neglect. What changes with AI agents is speed and scale. A person with stale access may never use it. An agent acting for that person will use whatever access it has, as often as its task requires, without pausing to ask whether the authority still applies.

Why the old permission keeps working

Most access models answer one question: does this identity have this permission? They are much weaker at a second question: is the reason this permission was granted still true?

A grant made for a specific task, a specific period or a specific role carries an implied condition. When the task ends or the person moves, the condition lapses, but the permission does not know that. Unless someone revokes it, it keeps working. Quarterly access reviews catch some of this, weeks or months after the fact.

When an agent acts with that permission, three things make the gap harder to see:

  • The agent's activity looks legitimate, because the credential is valid.
  • The person may not know the agent still has the access.
  • After the event, the logs show that something ran. They rarely show whether anyone was still entitled to authorise it.

The control question

A useful test is simple: would this action still be authorised if someone asked today? Not "was the credential valid", but "is the authority behind it still current?"

Putting that test into an agent workflow means three things:

  1. Authority is tied to its reason. A permission granted for a task or a period carries that scope and an expiry, rather than being an open-ended grant.
  2. Expiry and revocation are enforced at the point of action. When the authority has lapsed or been revoked, the action is refused, not merely flagged in a later review.
  3. The decision is recorded. Each allowed or refused action leaves a record of who or what requested it, the result and the reason, so a reviewer can see why the action was or was not permitted.

What IntelXview's AI Control Plane does here

For actions that are routed through it, IntelXview's AI Control Plane (ACP) checks each request against the authority the agent has been given before it runs. A paid proof of concept can test exactly the situation above on one agreed workflow:

  • Authority: restrict the agent to the permission that was agreed.
  • Expiry and revocation: test what happens when that permission has expired or been revoked. The test checks that the action is refused and that the refusal is recorded.
  • Evidence: inspect the decision record for each allowed and refused action. Our published decision evidence example shows the kind of record involved: the actor, the result, the reason and a signature that can be checked.

There are limits. ACP controls only activity routed through it; an agent or tool that bypasses it is outside these controls. A proof of concept usually starts with a controlled demonstration on synthetic data, and installation in your environment is a separate, scoped stage.

Where this comes from

This topic came from a LinkedIn post in September 2026 about a month-end access grant that was still active in October. One practitioner replied that they were dealing with exactly this problem and planned to apply the "would it still be authorised today?" test to their team's access management. That is one conversation, not a survey. It is a recognisable problem, and one that is easy to test on a single workflow.

Next step

If an AI agent in your organisation acts on access granted for a task or role that may have ended, book a free scoping call to discuss testing it on one workflow. If you advise clients on access or AI adoption, book a partner call instead. See what a PoC includes or how partner work is organised.