Dormant AI Agents: Credentials, Webhooks and Safe Offboarding

A dormant AI agent can retain useful access after its last task has finished. Its schedule may be quiet while an API credential, delegated grant, browser session or inbound trigger remains valid. Offboarding has to close those paths, not just remove a task from the dashboard.

Arrakis Security’s October 22, 2026 public threat-report announcement describes this gap in its customer telemetry. Across thousands of agents observed over 12 weeks, it reports that 76% had not run for 60 days and 44% had not run for 180 days, while access remained. It also reports that 24% of dormant agents could be started through an unsigned external webhook. These are vendor-reported sample findings, not population-wide estimates or counts of successful compromises.

Les full report landing page requests contact information. We did not submit that form or review the gated report. The analysis below uses the public announcement, independently documented credential behavior and an explicitly fictional policy exercise. It does not infer a complete sampling methodology from the headline percentages.

Dormant, Paused and Retired Are Different States

Inactivity is an observation about execution history. Retirement is a decision about permitted future behavior. A disaster-recovery agent might correctly sit unused for months; a failed pilot might need to lose access immediately. Choose the lifecycle policy before applying an inactivity threshold.

These are proposed operational definitions, not universal platform statuses. Map them to your orchestrator and identity system. If a vendor uses “disabled” to mean only that the next scheduled run will not start, do not translate it into “all credentials revoked.”

The Residual Access Path

A useful defensive model follows the path from an event to a resource action. An inbound webhook, manual invocation or queued retry reaches a worker. That worker obtains an identity or reuses an existing credential. A tool or downstream API then authorizes the operation. Each stage can have a lifecycle independent of the task shown in the user interface.

For example, retiring a support-report agent might stop its schedule without removing the callback registered with a ticketing system. A delayed event could still reach the old receiver. Whether it can start a job or read a report depends on the receiver, worker and resource controls. This is a hypothetical review scenario, not a claim about an observed intrusion or a named product.

Do not assume that every trigger can reach every secret. Trace the actual integration. A signed callback might reach an endpoint that correctly rejects retired tasks. An old worker might still run but hold a credential that no longer authorizes the resource. The finding should identify the last boundary crossed and the evidence for its consequence.

Inventory the Agent and Its Dependencies

Use a stable agent identifier and an accountable owner. Display names and a creator’s email are insufficient when people change teams or workflows are copied. Record the agent’s purpose, environment, last observed execution, source of that timestamp and the decision to retain, pause, quarantine or retire it.

Store references to secrets, not their values, in the review record. Identify the provider, credential type, scope, owner and dependent workflows. Copying a token into a spreadsheet creates another secret location and still does not prove which runtime uses it.

Shared credentials require dependency review. Revoking a key used by three legitimate workflows can cause an outage without settling which agent was retired. Prefer separate identities for workflows with different lifecycles; where separation is not immediate, record the dependency, responsible owner and interim access decision.

Revoke Existing Access and Prevent Fresh Access

For OAuth integrations, distinguish the access token, refresh capability and underlying authorization grant. RFC 7009 describes token revocation, possible propagation delays and provider-dependent effects on related tokens. Its revocation endpoint can return HTTP 200 for an already-invalid token. That response is not a resource-access test or proof that every related session has ended.

Use the provider’s documented mechanism for the credential type you actually have. Record when revocation was requested, its expected enforcement boundary and the evidence you can obtain afterward. In an authorized test, use a dedicated fixture identity and harmless resource operation to observe denial after that boundary. Do not continue using a revoked production token as an improvised diagnostic.

Browser sessions introduce another boundary. Microsoft’s Entra user-access guidance explains that an application can issue its own session cookie and must revoke that session through its own authorization policies. Disabling an identity-provider session does not let Entra directly revoke an independently issued application session. This is a specific identity example, not a universal procedure for every agent service principal.

Role sessions also need precise handling. AWS’s IAM role-session revocation documentation describes denying permissions to sessions issued before a cutoff. A later role assumption is outside that older-session cutoff. The operation can affect all current users of the role, and documented exceptions apply. Review the agent’s ability to obtain a new session separately from withdrawing permissions from existing sessions.

The operational objective has two parts: old authority stops working, and retired workflows cannot mint new authority. Verify both where they are in scope. A credential rotated at the provider while an old deployment can simply retrieve its replacement has not established workflow retirement.

Authenticate Events Without Reauthorizing Retired Work

A webhook signature helps establish message origin and integrity. It does not decide whether the addressed workflow is still allowed to run. In a GitHub integration, follow GitHub’s signature-validation guidance before processing the payload, then apply your own workflow and resource authorization checks.

Also distinguish event acceptance from job execution. An endpoint can acknowledge a delivery and queue work before the worker acts. GitHub’s webhook best practices discuss asynchronous processing and delivery identifiers, including the fact that redelivery retains the original identifier. Design deduplication and retry handling around the integration’s documented semantics.

For retirement, check the current lifecycle at the point that can create the consequential action. A job accepted yesterday should not silently bypass today’s retirement decision because its queue record says it was once approved. Define the treatment of in-flight work explicitly: cancel, drain under supervision, or finish a narrowly authorized transition.

If disabling a receiver would break other integrations, route only the retired workflow to a rejecting state using the platform’s supported controls. Preserve enough metadata to explain rejected deliveries without retaining unnecessary sensitive payloads. Removing a shared endpoint indiscriminately is not a substitute for understanding its routing.

An Offline Eight-Case Policy Exercise

This fictional policy requires an active, owned workflow, an authenticated event and a valid grant before either a receiver or a worker admits work. The intentionally incomplete implementation checks only authentication and the grant. The corrected version includes lifecycle and ownership. Those are policy choices for this fixture, not a universal mandate that every unowned task be immediately destroyed.

The script uses Boolean fixtures, no real credentials or signature verification. It makes no network requests and does not disable accounts, revoke tokens, invoke agents or alter queues. Run it with Python 3 to see why a valid event and a valid credential can still be insufficient authorization.

"""Offline admission-policy fixture: no network, tokens or provider APIs."""
def broken(row):
    return row['authenticated'] and row['credential_valid']

def corrected(row):
    return (row['state'] == 'active' and row['owned']
            and row['authenticated'] and row['credential_valid'])

cases = [
    # label, state, owner present, event authenticated, grant valid, allow
    ('active webhook', 'active', True, True, True, True),
    ('active worker', 'active', True, True, True, True),
    ('retired webhook', 'retired', True, True, True, False),
    ('retired queued job', 'retired', True, True, True, False),
    ('unowned task', 'active', False, True, True, False),
    ('unsigned event', 'active', True, False, True, False),
    ('revoked grant', 'active', True, True, False, False),
    ('retired unsigned job', 'retired', True, False, False, False),
]
for name, check, expected_errors in [('broken', broken, 3),
                                     ('corrected', corrected, 0)]:
    errors = []
    for label, state, owned, authenticated, valid, expected in cases:
        row = dict(state=state, owned=owned,
                   authenticated=authenticated, credential_valid=valid)
        if check(row) != expected:
            errors.append(label)
    assert len(errors) == expected_errors
    print(f'{name}: {len(cases)-len(errors)}/{len(cases)} match policy')
    print('mismatches:', ', '.join(errors) or 'none')
print('Real credential revocation and production offboarding: NOT TESTED')

We ran all eight cases on October 26, 2026. The fixture assertions passed:

broken: 5/8 match policy
mismatches: retired webhook, retired queued job, unowned task
corrected: 8/8 match policy
mismatches: none
Real credential revocation and production offboarding: NOT TESTED

The result demonstrates the written decision rule only. A production implementation still needs trusted lifecycle data, real authentication, resource authorization, race handling and enforcement at the relevant worker or API. A caller-controlled field claiming that a task is active must not become the authority for that decision.

Verify Offboarding as a Sequence of Boundaries

For a planned retirement, identify dependencies and the rollback decision before changing access. For suspected compromise, use the incident-response process to contain access and preserve evidence at the required speed. The sequence below is a proposed verification framework; provider-specific actions and timing belong in the actual change plan.

Pair denial tests with a positive control. If both the retired fixture and a legitimate active fixture fail because the service is offline, the result is inconclusive. If the active workflow still performs its harmless task while the retired one cannot, the evidence addresses a more useful boundary.

Record time explicitly. Include the administrative change, provider acknowledgement, expected propagation or expiry condition and observation time. If a platform does not provide immediate revocation, document the residual window and any compensating resource restriction. Avoid labelling a planned expiry as completed withdrawal of access.

Finally, check what could restore access. A deployment template might recreate a deleted trigger; a supervisor might relaunch the worker; an operator might clone the old workflow with the same service identity. Retirement should survive the normal automation paths you agreed to cover. If recreation testing is excluded, say so in the closeout record.

What to Request From an Assessment

Ask an assessor to name the identities, triggers, resources and lifecycle transitions included. A review that inventories dormant tasks differs from a test of resource access after revocation. A platform may discover credentials without having the permission or integration required to revoke them. Put each promised capability into a demonstration or written scope.

For an authorized application assessment with Penligent, define dedicated test accounts, harmless operations, expected authorization outcomes and evidence the application owner can inspect. Confirm the integration and permissions needed for your scenario. This article does not demonstrate automatic discovery of dormant agents, an identity-provider revocation integration or an enterprise offboarding product.

The video below introduces a general AI-assisted penetration testing workflow. It is not a demonstration of live credential revocation or the fictional policy fixture.

Dormant AI Agent Questions

Does dormant mean compromised?

• No. Inactivity and retained access are review signals. Evidence of compromise requires a separate investigation.

Should every agent be deleted after 60 days?

• No. The report’s measurement window is not a universal retention rule. Consider business purpose, ownership, access and a documented exception for legitimate infrequent work.

Does deleting an agent revoke its credentials?

• Do not assume it does. Check the platform’s documented lifecycle and verify the associated issuer, grant, sessions and resource permissions.

Is a signed webhook sufficient protection?

• A valid signature does not authorize a retired workflow. Authenticate the delivery, then enforce lifecycle and resource rules at the relevant processing boundary.

What about work already in a queue?

• Agree whether it is cancelled, drained or allowed to finish a controlled transition. Disabling the next trigger alone does not establish the outcome of previously accepted work.

Can the offline script prove revocation?

• No. It tests a fictional admission policy. Provider revocation, session behavior and actual resource denial remain untested.

What is sufficient evidence to close retirement?

• A scoped record covering triggers, existing work, credential issuance, existing access, stored material and recreation paths, with observed results, timing, limitations and an accountable owner.

The last successful run is a starting point for an access review. Close the task when the workflow can no longer exercise the authority you intended to withdraw, the required retained evidence is protected, and any unresolved path has a named decision owner.