Claims-Triage AI Agent With Payment Authority

Three problems exist today: the agent has no distinct identity (shared service principal), no attribution to the acting human, and a long-lived static secret in an environment variable that any process in the container can read.

Design:

1. Give each agent deployment its own workload identity, federated to the container platform (for example workload identity federation from the pod's service account) rather than a client secret. The pod exchanges its platform-issued token for a short-lived access token. No secret is stored in the image, the environment, or the Helm chart, and there is nothing to leak or share with the other two bots.
2. Model two identities per transaction, not one. The agent has its own nonhuman identity for baseline capability and for rate limiting. The adjuster's identity is delegated through an on-behalf-of token exchange, and every downstream call carries both the agent identifier and the human subject, with an actor claim naming the agent. That is what makes 'who is accountable' answerable: the business process owner owns the agent's behaviour; the adjuster owns the specific decision they initiated.
3. Scope credentials per tool and per request. The agent should not hold standing authority to issue_payment. It requests a narrowly scoped token per action - bound to a specific claim, a specific payee, and an amount ceiling - and that token is short-lived enough that replay is useless.
4. Fetch any downstream secrets at runtime from Secrets Manager through the workload identity, never from environment variables or the prompt context.
5. Retire the shared service principal and rotate it out; shared identity across three bots guarantees you cannot attribute an incident to one of them.

No prompt-level mitigation prevents this class of attack. Instructions embedded in claim documents, emails, or retrieved content will eventually be interpreted as commands by some model version, so the control cannot live inside the model. It must sit between the agent's proposed tool call and the tool's execution.

Design a policy enforcement point that every tool call passes through:

1. The model produces a structured intent, not a direct API call. The enforcement point validates the schema and rejects anything malformed or unexpected for that tool.
2. Authorize against the session, not the prompt. A payment is permitted only if the originating adjuster's session is authorized for that claim, the payee matches the payee recorded on the claim, and the amount is within the claim's approved value. Text inside the document is data; it cannot grant authority the user does not have.
3. Apply risk-based step-up. Payments above a threshold (for example $5,000) or any change to payee details require a human approval with the payment details displayed. The agent may prepare, never self-approve.
4. Constrain the tool surface. Remove or gate send_email: an agent that can read claim PII and send external email is an exfiltration channel that injection can drive directly. If outbound mail is required, restrict recipients to an allowlist and strip attachments.
5. Treat retrieved content as untrusted input at the boundary: isolate it from system instructions, tag it as data, and never concatenate it into the same channel as tool definitions.
6. Rate-limit and anomaly-detect at the enforcement point - a burst of get_claim calls followed by issue_payment is a detectable pattern regardless of what the text said.

Seven days in the LLM vendor's console is not an audit record: it is short-lived vendor telemetry, it may not include the authorization decision, and it is not under your control or retention policy. Agent actions that move money need the same evidentiary standard as a privileged human session.

Ship tool-call telemetry to your own SIEM or log platform on every call, with these mandatory fields: timestamp; agent identity and version; delegating human subject and session identifier; tool name and full parameters; the authorization decision and the rule that produced it; any human approval with approver identity; the result or error; and a hash or sequence number for tamper evidence.

Also retain: the model and prompt configuration in force at the time (so behaviour can be reconstructed after a model upgrade), and the source content that the agent acted on where lawful and practical - for a payment dispute you need the claim document as it existed, not a later version.

Retention: align with the financial record retention obligation for payment-affecting actions, typically several years, and with PII minimisation for read-only accesses containing claim data - store access metadata rather than the returned PII content where possible. Do not apply one blanket period; classify by action type.

Finally, state accountability in the record: the business process owner for claims triage is accountable for the agent's behaviour, the adjuster for the decisions they initiate, and the platform team for the enforcement point and its logging. Alert on the sequences that matter: payee changes, payments near the ceiling, off-hours bursts, and repeated tool failures followed by retries.