A pilot agent may look switched off in its dashboard while a connected app, scheduled job or delegated session still needs attention. Whether that happens depends on the actual integration. Before you grant access, write down who can take it away, and how that person will show the connected system now says no.
Give each connection an owner, an effective scope, an expiry trigger and an offboarding check. A green “disabled” badge in the agent UI is not, by itself, evidence from every app the pilot touched.
Start with the authority, not the demo
Approving an agent’s draft ticket is one decision. Giving its connected app permission to create tickets is another. A review screen can stop a proposed action without changing the underlying permission; an instruction in a prompt cannot enforce a ticket system’s access policy.
OWASP calls out three distinct sources of excessive agency: too much functionality, too much permission and too much autonomy. It recommends enforcing authorization in downstream systems rather than leaving that decision to the model (OWASP LLM06:2025, accessed 25 September 2026). If your immediate question is which actions need a human sign-off, read our separate guide to human review in AI workflows. Here the decision is who grants and removes the capability itself.
One connection, one access record
Imagine an invented pilot in a test ticket queue. The agent reads a few synthetic tickets and prepares an internal draft ticket. It cannot publish a customer reply or see live customer records. The sample record is a conversation starter, not a vendor configuration.
| Pilot task | Connected resource and action | Accountable owner | Exit trigger | Evidence to request |
|---|---|---|---|---|
| Sort test tickets | Defined set of synthetic tickets; read only | Test-queue owner | Pilot ends or owner changes | Grant removed in the ticket app; repeat read of a test ticket denied |
| Prepare a draft ticket | Sandbox drafts; create, not publish | Ticket-app administrator | Same trigger; earlier if scope changes | Create permission withdrawn; harmless draft attempt denied |
The plate shows the offboarding sequence; the record above carries the accountable owners and requested evidence. This is an invented scenario, not a live provider audit.
For the real version, add which identity actually calls each app: dedicated agent identity, delegated user or another arrangement. Record the pilot owner who approves access and the app owner who can remove it. The effective scope is what the downstream app will allow, not just the tool label shown to the agent. Keep credentials, real record identifiers and raw logs out of this shared record.
Microsoft’s agent guidance recommends a stable, lifecycle-managed identity with a named human owner, narrowly defined resources and task-based permissions. Temporary entitlements can expire without creating a fresh identity for every task (Microsoft Security, 16 July 2026). Treat that as a design pattern to test against your own stack, not a claim that every app provides it.
Make expiry a decision, not a calendar decoration
Choose a planned end date or a clear trigger before launch. A new app, a wider dataset, a different workflow or a departing pilot owner should also reopen the access decision. Name who initiates the review and who performs the change in each app. Where the provider has no automatic expiry, a spreadsheet reminder is only a reminder: require a human removal step and a check of the result.
Some products do offer time-bounded access. Okta Identity Governance documents an access duration followed by automatic revocation for requests to linked apps within its product (Okta Identity Engine documentation, accessed 25 September 2026). It does not establish how your ticket tool, job runner or other provider behaves.
At review time, do not roll the date forward by default. Have the pilot owner confirm the task still exists, check the actual permissions against it and record one of two decisions: renew with a new end point, or begin offboarding. Microsoft Learn advises re-review when workflows, tools, data scope or deployment environment materially change (least-privilege pattern, accessed 25 September 2026).
What does “disconnect” leave behind?
Ask five different questions, not one vague “is it off?”
- Agent runtime: Are new runs stopped in the agent interface? Who can restart them?
- App grant: Has the role or permission actually been removed where it was issued?
- Session or credential: Does the provider require separate invalidation, and how will its owner confirm that? Do not assume an identical revocation delay across apps.
- Queued work: Can a scheduled run or pending action still execute? Assign someone to cancel or resolve it.
- Existing output: What happens to any data or draft already produced? Removing future access does not erase earlier copies.
This is an inventory for the owners of the systems, not a recipe for manipulating live credentials. Microsoft explicitly recommends testing revocation paths, including disabling identities, invalidating tokens and removing stale permissions (Microsoft Learn, accessed 25 September 2026). When an active agent has already taken a wrong action, follow an incident-response path instead. An orderly pilot exit cannot undo an incident. Our indirect prompt injection guide addresses hostile content, not scheduled offboarding.
Ask for a deny test where the permission lived
After the app owner removes the grant, check the app’s access state and attempt the previously permitted read or draft against a safe, synthetic test resource. Record the refusal, the app checked and the person who witnessed it. Where an actual deny test would be unsafe or unsupported, record “not verified” and have the provider describe an alternative. Do not convert a UI click into a claim that all downstream paths were revoked.
The handover needs a short, non-sensitive closure record: the app and non-sensitive scope, owner, change date, result of the check, pending-work disposition and the decision to close or renew. It is evidence for your pilot decision, not an IAM certification. It says nothing on its own about copies of data already exported.
Six handover questions worth getting answered
Ask the provider and your internal app owners for a redacted record and a demonstration on test data:
- Who approved this pilot and who can remove access in each connected app?
- Which identity holds the permission, and what can it actually read or change downstream?
- What ends the grant, and who takes over the review if the pilot owner leaves?
- Which runs stop with “pause”, and which app grants, sessions or queued jobs need separate action?
- Where will we see a harmless request denied after removal?
- Who signs a renewal or closure, and where is its non-sensitive evidence kept?
If nobody owns the fifth answer, delay that connection. Deciding between a direct API and MCP is an integration-boundary decision; neither interface supplies an exit plan by itself.
Connecting an agent for a limited trial? Map the access, owner and offboarding proof around one real workflow before the pilot starts. Tell us what you need to test without sending credentials or customer records.
