Borrowed Credentials Break the Audit Trail

An illustrative finance employee asks an invoice-exception agent to reconcile a mismatch. The agent reads the purchase order, contract, invoice, and approval policy, then updates the ERP using the employee’s OAuth token. The audit log says the employee changed the record.

They did not review the final payload. The agent performed the action. If the same workflow is triggered by a finance director, it may also inherit broader access than the exception requires.

Borrowed credentials collapse three separate questions: who requested the work, which identity executed it, and what authority the workflow should have.

The invoker and the actor serve different purposes

The invoker tells the system who asked for the task and what information may be returned to that person.

The actor tells the target system which identity is performing an action. That identity determines permissions, attribution, rate limits, and audit behavior.

The approver supplies human authority when the action requires judgment or exceeds the agent’s delegated boundary.

One person can occupy all three roles in a manual process. An autonomous or scheduled agent makes the separation visible. A useful action record should retain each role rather than recording only the credential accepted by the ERP.

User tokens create inconsistent authority

If an agent borrows the invoker’s access, its behavior changes by user. A junior employee may be unable to run a legitimate workflow because they lack direct access to a source. A senior executive may grant the agent far more visibility and action authority than its role requires.

Long-running work adds token expiry and revocation. A workflow can begin with access and fail hours later after the user session ends. Retrying under a different user can change the available records.

The design question is how workload identity, user permissions, delegated authority, and approval interact. Giving the agent its own identity can improve attribution, but that identity still needs a narrow purpose and a policy for whose authority applies to each action.

A dedicated identity still needs a narrow purpose

Creating a service account does not solve authorization by itself. A permanent credential with broad ERP access can increase risk.

The identity should be scoped to the workflow’s required records and actions. For the invoice exception, that could mean reading specified purchasing and contract objects, creating a case note, and updating a limited set of fields only after policy checks. Payment release and changes above a threshold remain outside the role.

The Coryntas security and governance model begins with identity and purpose, then evaluates policy and authority at the point of action.

Credential management also becomes an operating responsibility: provisioning, secret storage, rotation, revocation, ownership, and review all need a defined process.

Attribution must survive every system handoff

The ERP may only record the service account. The workflow evidence should additionally record:

• requesting user and channel;
• agent and release identifier;
• purpose and case identifier;
• source evidence used;
• policy result;
• human approver where required;
• exact proposed and committed changes; and
• target-system record identifier.

This creates an audit trail that can answer what happened without falsely attributing the work to a person who never saw it.

The invoice exception workflow also preserves separation of duties. An agent can prepare, reconcile, and complete permitted actions without acquiring authority reserved for finance owners.

Identity does not remove the need to stop

Some source systems do not support sufficiently narrow workload permissions. Some actions cannot carry the desired attribution metadata. Some APIs make it difficult to distinguish a committed write from a failed request.

In those conditions, the workflow may need to propose an action for a person to execute or use a controlled intermediate service. That adds friction, but it keeps the authority model honest.

An agent should be visible as the actor when it acts. The human requester and approver should remain visible too. Clear identity turns the audit trail from a login record into an account of responsibility.