Your AI Agent Finished the Task. Why Does It Still Have the Keys?

The agent finished at 4.17pm.

It compared the invoices, checked the purchase orders, flagged three discrepancies and sent a tidy summary to finance. The employee who started the task closed the window and went home. The agent did not.

Its token was still valid. Its connection to the finance system remained open. The permissions it had inherited from the employee were still attached. Nothing on the screen announced this. No siren sounded. The work was over; the authority was not.

This is how a great deal of organisational risk begins: not with a spectacular failure, but with an access right that outlives its reason.

Companies have spent the past year writing policies about what AI may see. Far fewer can enforce those rules while an agent is working, or remove its access when the job ends. Delinea surveyed 2,254 IT and security leaders and 2,250 employees in September 2026. Almost every organisation—99.7%—had a formal policy governing AI access. Only 51% checked access against that policy in real time. Meanwhile, 42% said many agent credentials remained active until an audit. Just 19% detected the most recent out-of-scope access while it was happening.¹,⁶

Delinea sells identity-security software, so its framing serves a commercial interest. But the problem it describes is not confined to one vendor’s report. Microsoft now advises organisations to give agents distinct identities, named human sponsors and time-limited privileges; NIST has launched a standards initiative focused partly on agent identity and security. The direction is clear: organisations cannot govern an AI agent as though it were a chat window once it starts acting across systems.¹,²,³,⁵

Here is the principle organisations need now:

That sounds technical. It is actually about management. The technology team can make a credential expire. Only the organisation can decide when the agent’s authority has expired with it.

• 01 / THE QUIET LIFE OF A PERMISSION

The quiet life of a permission

Access is easy to grant because it is attached to momentum.

A pilot needs customer data. Coding agents need repository access; support agents need the ticketing system. Someone approves the request because the deadline is close and the demonstration is on Thursday. The agent works. Everyone congratulates the team. The pilot becomes a workflow; the workflow becomes infrastructure; the access becomes background.

Revocation has no launch event. It creates no demo. Nobody receives a promotion for remembering that an abandoned service account can still read payroll data.

This is not a new weakness. Employees have always accumulated access as they move between jobs and teams. Shared accounts have stayed alive after their owners left because nobody knew what disabling them would break. Software integrations have always collected more privileges than their narrow purpose required.

However, AI agents make this old problem harder in three ways.

First, they can act rather than merely retrieve. An agent with access to a customer system may not only read a record; it may update, copy, classify, send or delete information. Second, it may move through several tools in one run. A permission that appears harmless in isolation may become consequential when combined with email, a database and the ability to invoke code. Third, an agent can perform these actions at a pace that turns a small boundary error into a large operational event before anyone notices.

Even so, the common response is to produce another policy. But Delinea’s survey found an almost perfect rate of policy adoption alongside much weaker enforcement. That is the point. Policy describes what should happen. Permission determines what can happen.¹,⁴

“Policy describes what should happen. Permission determines what can happen.”

If the system allows an agent to continue reaching sensitive records after the task has ended, the policy is not governing the agent. It is expressing a preference.

• 02 / THE AGENT MAY BE WEARING YOUR BADGE

The agent may be wearing your badge

Many agents do not have an identity of their own. They act through the account of the person who launched them or inherit that person’s permissions.

It is convenient. The employee can already access the shared drive, CRM and calendar, so the agent can use the same access instead of waiting for a separate identity to be configured. As a result, deployment becomes faster. The audit trail becomes fiction.

Suppose an employee can view every client record in a region because her job occasionally requires it. She asks an agent to prepare notes for six accounts. If the agent inherits her full permissions, it may be technically able to inspect hundreds of records. The agent has turned the employee’s entitlement into an opportunity.

The distinction matters even if the agent behaves perfectly. A system record may show that the employee accessed a file when the agent made the request. Investigators may be able to see what account was used without seeing which actor acted, which instruction initiated the request or which person approved the delegation.

Only 36% of the IT leaders in Delinea’s study said they could always connect sensitive AI access to a named human authoriser. In India, the reported figure was 47%—better, but still less than half.¹,⁴,⁶

For that reason, an agent needs its own identity. Not a friendly name in a dashboard. A distinct, governable identity that allows an organisation to tell:

Microsoft’s current guidance treats agent identities as a separate identity type, with their own access rights and a human sponsor responsible for lifecycle and access decisions. It also recommends keeping the identity stable while making elevated permissions temporary through short-lived tokens, approvals or just-in-time access.²

The distinction is useful. The agent may keep its identity. It should not keep every key it has ever borrowed.

• 03 / ACCESS IS NOT AUTHORITY

Access is not authority

The language of permissions can make an organisational decision sound like a software setting.

A user has read access. An application has write access. An agent has permission to call a tool. The team ticks the boxes, the connection works and the configuration appears correct.

In other words, technical access and organisational authority are not the same thing.

A sales director may access a pricing system, but company policy may still bar them from changing every contract. A manager may see an employee’s record without being free to repurpose it. An agent may send email through a user’s account without having authority to promise anything to a customer.

The question is not simply, can the agent do this? It is, under which circumstances has the organisation agreed that it may?

That distinction builds on a broader governance problem explored in my AI Agent Has a Job. Who Is Managing It? An agent needs a defined job, an owner, observable behaviour and someone with the power to intervene. Permissions are where that job description becomes real. If the role says “prepare a refund recommendation” but the credentials allow the agent to issue refunds, the credentials have quietly rewritten the role.

The same is true of workflow design. As argued in A Workflow Is a Better Starting Point Than a Tool, organisations should decide how work and decisions ought to move before inserting new software. The workflow should determine the agent’s access. Too often, the available integration determines the workflow instead.

That is how convenience becomes authority without passing through a decision.

• 04 / STOP ISSUING MASTER KEYS

Stop issuing master keys

Organisations tend to choose between access and no access. Agents require a more precise vocabulary.

Instead, the preferred default should be task-bound access, with separate approval for high-consequence actions. The agent receives what it needs for this piece of work, not whatever the person launching it happens to possess.

Security teams call this least privilege and just-in-time access. The phrases are accurate but easy to exile to a technical document. In ordinary language, they mean: give the agent the smallest useful key, as late as possible, and take it back as soon as the work is done.

This approach is becoming more practical. Microsoft recommends a stable agent identity combined with temporary entitlements for specific workflows. Delinea describes issuing a credential at the moment of access, limiting it to the task and revoking it automatically when the task completes.²,⁵

However, none of this removes the need for judgement. “Task complete” can be surprisingly difficult to define.

For example, has a customer-support task ended when the reply is sent, when the customer confirms resolution or when the case closes? If an agent creates a report every night, should its database access exist throughout the day? If a workflow pauses for human approval, should the agent retain all its permissions while it waits?

The identity platform cannot answer these questions alone. The people who understand the work, its exceptions and its consequences must decide them.

This is why Who Actually Owns AI Risk in Your Organisation? matters here. Security can operate access controls. It should not unilaterally decide the business conditions under which an agent may act. The process owner must define the purpose; security must translate it into enforceable limits; risk and legal teams must identify the consequences; the accountable executive must accept what remains.

A permission without an owner is simply an organisational decision that nobody remembers making.

• 05 / GIVE EVERY PERMISSION A CLOCK

Give every permission a clock

Every agent permission should answer three questions:

If one answer is missing, the access is not ready for production.

A useful permission record should contain:

This does not need to become an eleven-page form. It can be a machine-readable record supported by a short, legible summary for humans. The point is not paperwork. The point is to make authority explicit enough to automate its end.

Expiry should be the default. Renewal should require a reason.

By contrast, access commonly continues by default while removal requires intervention. This places the burden on someone remembering that an agent exists, finding its credentials, understanding its dependencies and being brave enough to switch it off.

The emerging identity platforms acknowledge this lifecycle problem. Microsoft’s agent-governance model includes human sponsors, access packages, lifecycle workflows and reassignment when a sponsor changes role or leaves the organisation. That last detail matters. An agent whose human owner has departed should not become a small digital estate with no known heir.²

• 06 / INDIA’S POLICY GAP IS AN ENFORCEMENT GAP

India’s policy gap is an enforcement gap

The Indian findings make the issue harder to dismiss as a problem for distant technology companies.

According to Delinea’s India findings, 84% of surveyed organisations experienced an incident involving access beyond an AI tool’s intended scope. Yet 99% reported having a formal policy. Forty-five per cent said some credentials remained active until the next audit after the task ended. Only 47% could always identify the person who authorised sensitive access.⁶

India performed better than the global sample on some enforcement and detection measures. Even so, better performance than the global sample offers no reason for comfort. The combination of broad AI adoption, large service operations and high-volume handling of customer, employee and financial information makes access discipline a business requirement, not an optional security upgrade.

India’s data-protection framework also makes the issue concrete. Rule 6 of the Digital Personal Data Protection Rules, 2025 requires appropriate measures to control access to computer resources and visibility through logs, monitoring and review so unauthorised access can be detected, investigated and remedied. The rules also require relevant logs to be retained for one year, unless another law requires otherwise.⁷

An organisation cannot meet the spirit of those requirements by knowing that “the AI platform” touched personal data. It needs to know which agent accessed what, under whose authority, for which purpose and with what result.

Therefore, this should change how Indian organisations buy and deploy agent systems. Before a vendor demonstration, ask whether the platform can:

These questions belong in procurement, not in the post-incident review. The AI Vendor Risk Checklist Nobody Runs Before Signing the Contract explains why vendor assessment must extend beyond model quality and contractual reassurance. If the product cannot show, constrain and end an agent’s authority, the problem has already entered the architecture.

• 08 / SHADOW AGENTS COLLECT REAL KEYS

Shadow agents collect real keys

Official agent programmes are not the only source of persistent access.

Meanwhile, employees continue connecting AI tools to drives, calendars, messaging platforms and repositories because doing so makes the tool useful. They approve integrations quickly, often through familiar consent screens. A small experiment gains access to a large working life.

Delinea’s survey found that 76% of employees said they had bypassed required approval at some point to use AI with company data, systems or applications. Separately, only 41% of IT leaders said every AI tool and agent accessing company data was actively monitored.¹,⁶

Still, the answer is not another threatening email. Slow, opaque approval processes teach employees to treat governance as an obstacle. If the sanctioned route takes three weeks and the unsanctioned tool takes three minutes, urgency will make the decision.

As Shadow AI Is Already Your Operating Model argues, unauthorised use is often evidence about the organisation’s real workflow: people are trying to solve a problem the formal system has left unresolved. The response should combine discovery and control with a faster path to legitimate access.

That means:

People should not have to choose between completing the work and following the rules. But convenience cannot mean leaving every experimental agent with a permanent staff pass.

• 09 / RUN THE EXPIRY TEST

Run the expiry test

This article does not need to end with a grand framework. It needs to end with a calendar invitation.

Bring together the business owner, identity or security lead, product team and the people who use the workflow. Choose one live or proposed agent. Do not discuss AI strategy. Ask these questions:

Ultimately, the exercise will reveal whether the organisation gave the agent a bounded job or merely plugged it into accumulated privileges.

Companies are understandably eager to make agents more capable. The market rewards connection: another inbox, another database, another workflow completed without a person touching it. Capability is visible. Restraint is not.

But an agent’s usefulness does not increase with every permission it retains. Past a certain point, the organisation is no longer enabling the work. It is leaving authority lying around.

References

1. 2026 Identity Security Report: The AI Enforcement Gap — Delinea, September 2026.
2. Governing Agent Identities — Microsoft Entra ID Governance, 2026.
3. AI Agent Standards Initiative — NIST, 17 February 2026.
4. AI Governance Has an Enforcement Problem — Delinea, September 2026.
5. Delinea Delivers Runtime Authorisation for AI Agents — Delinea, 2026.
6. AI Access Policies Fail at the Point of Enforcement in Indian Organisations — Delinea, 2026.
7. The Digital Personal Data Protection Rules, 2025 — Ministry of Electronics and Information Technology, 2025.