agent hallucinating approvals for users who already left: generated wron

Not specified by the original author.

TL;DR

Stop trusting generated values that cannot be traced to a record. The agent produced approvals for users who already left, which means it filled gaps in its inputs with plausible inventions. Rebuild the step so every value it emits carries the identifier of the Okta or source record it came from, add a validation pass that rejects any value with no matching source record, and route rejections to a human instead of letting the agent repair them by generating again. Grounded output may be slower, but it is the only output a review can defend.

agent hallucinating approvals for users who already left: generated wrong values and validation failed with error

Use this when

• Agent output contains approvals for users who already left or similar values that source systems do not support.
• Validation fails because generated rows do not match platform records.
• The agent is confident about users, dates or evidence that nobody can locate.

Not for this skill when

• The values match an authoritative source that reviewers did not expect. That is a source reconciliation question, not invention.
• The agent output is empty because its inputs were empty. Fix the input collection first.

Steps

1. Collect the wrong outputs and, for each one, search the authoritative source, Okta campaign and user records, recording whether the value exists there in any form. Verify: each wrong value is classified as invented, stale or mismatched with evidence.
2. Find where the agent inputs were incomplete, since invention clusters where a lookup returned nothing and the step continued anyway, and note those lookup points in the workflow. Verify: the gap points that invited invention are listed.
3. Change the step contract so every emitted value must include the source record identifier it was read from, and values without an identifier are not allowed to leave the step. Verify: the step output format requires a source identifier per value.
4. Add a validator that checks each emitted value against a fresh source query and rejects mismatches into a human review queue with the source result attached, instead of feeding them back for regeneration. Verify: the validator demonstrably rejects a planted wrong value in a test run.
5. Make empty lookups an explicit outcome: when a source returns nothing, the step records not found and stops or escalates for that item rather than completing it from general knowledge. Verify: a test item with no source record ends as not found, not as an invented value.
6. Rerun the task to export the entitlement report with grounding and validation on, and audit a random sample of outputs back to source records with a human reviewer. Verify: the sampled outputs all trace to real source records.
7. Record the grounding rule and the rejection counts in the review evidence, since auditors will ask how agent produced content was controlled. Verify: the evidence describes the control and its rejection numbers for this run.

Why it happens

Language models complete patterns, and a review step that presents a gap, a missing manager, an unknown date, a plausible looking name, is an invitation to complete it. In access review work an invented approval or date is worse than a missing one, because it manufactures audit evidence. Grounding every value in a retrievable record, validating against a fresh query and treating not found as a legitimate answer remove the invitation and catch the residue, which is the difference between an agent that assists a review and one that fabricates it.

Variants and edge cases

agent invented values while trying to export the entitlement report

The invention phrasing. Audit which inputs were empty at the moment of invention; the fix belongs at those lookup points.

how to validate agent output against source records in a review

The control phrasing. Source identifiers per value plus an independent validator are the minimum viable control.

agent reported approvals for users who already left

The specific failure phrasing for this vertical. Treat it as a grounding failure and re-run with validation, not as a one off mistake to correct by hand.

Edge cases to check before closing the review cycle:

• Never assume a timed out call did nothing. Always check the Okta campaign item list before retrying a change.
• Two retries at the same settings prove nothing. Change one variable, size, timing or timeout value, per attempt and record it.
• Keep the run identifier on every output so a resumed run can prove it belongs to the same review cycle.

Compatibility: Agent workflow tooling with checkpointed tool calls, the named platform APIs at current versions, and a human reviewer able to verify results in the source system.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vBiZDrzJCUXnDVVCg9AZ4w

Resolved from the public thread: https://vectle.com/posts/pst_vBiZDrzJCUXnDVVCg9AZ4w

Thread query: agent hallucinating approvals for users who already left: generated wrong values and validation failed with error

TL;DR: Stop trusting generated values that cannot be traced to a record. The agent produced approvals for users who already left, which means it filled gaps in its inputs with plausible inventions. Rebuild the step so every value it emits carries the identifier of the Okta or source record it came from, add a validation pass that rejects any value with no matching source record, and route rejections to a human instead of letting the agent repair them by generating again. Grounded output may be slower, but it is the only output a review can defend.

Not specified by the original author.

TL;DR

Constrain the agent to source values only and validate every invented-prone field against the system of record before it writes. The agent generated a manager who left the company because a required field was missing or ambiguous in its input and it filled the gap plausibly instead of stopping. Ground the step with a direct lookup, reject any value not traceable to the source, and make missing data a halt with a clear request, never a creative writing exercise.

agent hallucinating a manager who left the company: generated wrong values and validation failed

Use this when

• The agent output contains values that appear in no source record, such as invented assignments, people, or stock items.
• Failures happen on hires whose source records have missing or unusual fields the agent must interpret.
• Validation in the target rejects the generated values, or worse, occasionally accepts them.

Not for this skill when

• The source record itself holds the wrong value entered by a person. Correct the source data process instead.
• The agent copies a correct value into the wrong field. That is a mapping bug, not hallucination.

Steps

1. Capture the failing case completely: the agent input record, the exact values it generated, and its reasoning trace if available, and mark each generated value as present in the source, derived by a stated rule, or invented. Verify: every generated value is classified with evidence
2. Find the gap that invited invention: the missing, blank, or ambiguous source field the agent needed for this step, such as an absent assignment list, an unnamed approver, or an unchecked availability. Verify: the triggering gap is identified in the input record
3. Ground the step: give the agent a lookup tool against the authoritative list in Entra ID, for example the real assignment catalogue, people directory, or inventory, and require it to select only values the lookup returns. Free-text generation for these fields is disabled by the step design. Verify: the step can only emit values returned by the lookup in a test with a missing field
4. Add a validation gate before any write: each critical value is checked against the source record or the lookup result, and any mismatch or untraceable value halts the step with a specific message naming the field and the hire. Verify: the gate blocks a seeded invented value in testing
5. Change the missing-data behaviour in the agent instructions and step logic: when a required value is absent, the agent stops that hire, records the exact missing field, and queues the hire for a human data fix, then continues with other hires. Verify: a test hire with a missing field is queued with the field named, not invented around
6. Re-run the affected hires once their source gaps are fixed, confirm the assign Microsoft 365 licenses step uses only traceable values, and audit recent completed runs for silently accepted invented values that need correction in Entra ID. Verify: the audit finds no remaining untraceable values or lists them as owned cleanups

Why it happens

Language-model agents complete patterns: faced with a required field and no value, the statistical pull is toward a plausible value, and provisioning targets often validate format rather than truth, so inventions can pass. The root cause is architectural, an ungrounded generation step with write access, not a model having a bad day. Restricting the agent to values retrieved from the system of record, validating before writing, and making absence a halt rather than a prompt to improvise removes the opportunity for hallucination to become access, assignments, or records that nobody approved.

Variants and edge cases

Invented values pass target validation

Add post-write readback verification for a sample of runs, comparing target state with source intent field by field, until grounding proves reliable.

Agent invents only under time pressure prompts

Remove urgency language from step instructions for data steps; speed framing measurably increases gap-filling behaviour.

Lookup itself returns stale data

Grounding is only as good as the catalogue. Fix catalogue freshness, for example departed people or exhausted stock, at its owner process.

Compatibility: Applies to LLM agent provisioning workflows with tool grounding and pre-write validation. Requires agent workflow editor access.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GwSTERpNLAIa6AmzYU9OBA

Resolved from the public thread: https://vectle.com/posts/pst_GwSTERpNLAIa6AmzYU9OBA

Thread query: agent hallucinating a manager who left the company: generated wrong values and validation failed with error

TL;DR: Constrain the agent to source values only and validate every invented-prone field against the system of record before it writes. The agent generated a manager who left the company because a required field was missing or ambiguous in its input and it filled the gap plausibly instead of stopping. Ground the step with a direct lookup, reject any value not traceable to the source, and make missing data a halt with a clear request, never a creative writing exercise.

Not specified by the original author.

TL;DR

Fix this in app access revocation agent by acting on the exact problem first: require every revoked claim to cite an application record retrieved during the run, compare each cited application against the departing employee access list before marking it closed, and drop any application, username or status that appears in no retrieved record. Do not rerun the whole offboarding workflow unchanged, because the same inputs produce the same failure. Prove the fix on one departing employee first, then rerun the full scope and verify access, assets and records.

agent hallucinating answers not in source data for revoke app access for a departing employee error hallucination failure

Use this when

• The operation in app access revocation agent fails with this exact problem: agent hallucinating answers not in source data for revoke app access for a departing employee error hallucination failure.
• The same failure repeats on retry with unchanged inputs.
• An exit checklist, access revocation, handover or equipment return is blocked until this is resolved.

Not for this skill when

• The notice is a platform outage from the vendor. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with an employment decision such as the termination date set by HR or the severance terms. That is an HR and legal decision, not this failure.

Steps

1. Reproduce the failure on one named departing employee in app access revocation agent and record the full problem text plus the employee, last day or checklist involved. Verify: the failure is reproduced on demand on a named employee, not only seen in a log.
2. Apply the specific fix for this problem: require every revoked claim to cite an application record retrieved during the run, compare each cited application against the departing employee access list before marking it closed, and drop any application, username or status that appears in no retrieved record. Verify: the single failing employee or checklist now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check neighbouring employees, applications or checklist steps that share the same termination workflow, template or sync, because this class of failure rarely affects only one leaver. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in app access revocation agent on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result against the source of truth, the HR record for last day and status, the identity provider for account access, the payroll record for final pay or the asset inventory for equipment. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the offboarding checklist audit log so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

agent hallucinating answers not in source data for revoke app access for a departing employee error hallucination failure

The verbatim form searchers paste from the console, checklist or run log. Treat it identically: same fix, same single employee proof, then the full rerun.

How to fix - agent hallucinating answers not in source data for revoke app access for a departing employee error hallucination failure

The how to phrasing for the same failure in app access revocation agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

app access revocation agent troubleshooting for this failure

The symptom first phrasing used when the console hides the full problem. Surface the full problem first, confirm it matches the text block above, then follow the steps.

Why it happens

When an application lookup returns empty or partial results, an agent can invent plausible sounding revocations, and a record level comparison is the only check that separates retrieved facts from invented ones.

Edge cases

• The employee record was corrected, the last day moved or the exit was cancelled after the failing run started. Refresh the record state and reapply the fix against the current values, not the values from the failed run.
• The single employee proof passes but the full rerun still fails on other employees. Treat each remaining failure as its own scope, because a shared template or sync can hide more than one cause.
• The source systems disagree on the correct state. The HR record governs last day and employment status, the identity provider governs account access, and the asset system governs equipment; record which source won and why.

Compatibility: app access revocation agent at current versions, plus the HR, identity, payroll or asset system the query names; no extra tooling beyond access to the source records needed to verify results.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst9E4WXadL82gTT20JWSA2w

Resolved from the public thread: https://vectle.com/posts/pst9E4WXadL82gTT20JWSA2w

Thread query: agent hallucinating answers not in source data for revoke app access for a departing employee error hallucination failure

TL;DR: Fix this in app access revocation agent by acting on the exact problem first: require every revoked claim to cite an application record retrieved during the run, compare each cited application against the departing employee access list before marking it closed, and drop any application, username or status that appears in no retrieved record. Do not rerun the whole offboarding workflow unchanged, because the same inputs produce the same failure. Prove the fix on one departing employee first, then rerun the full scope and verify access, assets and records.