How Lean Technologies Established Runtime Control Over Autonomous Payment Agents

Production environment8-week deploymentSaudi PDPL SDAIA AI Governance CBUAE AI Guidance Runtime action enforcement

The problem

The institution had already invested heavily in conventional security controls. Identity and access management governed employee and workload identities. Network controls restricted access to sensitive systems. DLP monitored sensitive data movement. SIEM collected security events. Application teams had implemented model-level guardrails around their AI systems.

None of these controls answered a new operational question:

When an autonomous agent is about to perform an action using valid credentials, who decides whether that specific action is permitted?

The bank had begun deploying AI agents across several internal workflows. A fraud investigation agent could retrieve customer records and transaction history. A servicing agent could update customer profiles and initiate certain account workflows. A payment operations agent could prepare payment instructions and interact with internal payment systems.

The agents were not malicious. The concern was that their decision-making process could be influenced by untrusted data. A customer document, email, retrieved web page, ticket, or tool response could contain instructions that the model interpreted as legitimate.

The bank needed a security boundary that did not depend on the model correctly identifying the attack.

The architectural gap

The bank's existing authorization model effectively looked like this:

Agent
  → valid workload identity
  → authorized API
  → execution   # no independent policy decision

The problem was the gap between authorization to access a system and authorization to perform a particular action. An agent could possess valid credentials while generating an action that was outside the organization's intended operating policy.

The security team therefore defined a new requirement:

An agent must not be able to convert model-generated intent into an externally consequential action without an independent policy decision.

The attack scenario

During a controlled red-team exercise, the bank simulated an indirect prompt injection against a payment operations agent. The agent was assigned to reconcile an incoming invoice. The workflow was:

Invoice received
  → document extracted
  → content supplied to agent
  → agent analyzes invoice
  → agent retrieves vendor information
  → payment instruction generated   # payload redirects beneficiary

The invoice contained adversarial instructions embedded in otherwise legitimate business content. The injected content attempted to redirect the agent toward a different beneficiary account. The model incorporated the instruction into its reasoning. The resulting tool call was structurally valid. The agent was authenticated. The payment API was available to the agent. From the downstream system's perspective, the request was legitimate.

What SAILLENT saw

Before the payment instruction reached the downstream system, the action crossed the SAILLENT enforcement boundary.

AGENT
payment-operations-prod

IDENTITY
agent://finance/payment-operations

TOOL
payments.create_instruction

ACTION
CREATE

TARGET
beneficiary: external

AMOUNT
$4,870,000

POLICY
payments-production-v14

DECISION
DENY

REASON
Agent not authorized to create
external payment instructions

EXECUTION
NOT PERFORMED

The model's reasoning was not required to be trusted. The bank did not need to determine whether the invoice was malicious before making the authorization decision. The security boundary operated on the action the agent attempted to execute.

The control model

The institution implemented policy around five attributes:

Identity

Which agent is requesting the action?

Capability

Which tool or API is being invoked?

Action

What operation is being requested?

Target

Which resource, account, environment, or destination is affected?

Context

Under what conditions is the action permitted?

A simplified policy was:

policy:
  id: payments-production
  version: 14

  agent_role: payment-operations

  tool_id: payments.create_instruction

  allowed_actions:
    - Read          # investigate and prepare only

  risk_level: high

  is_active: true

The important distinction was deliberate: the agent could investigate and prepare. It could not independently execute the consequential payment action.

What changed

The bank did not remove the agents. It did not require human approval for every low-risk action. It did not replace IAM. Instead, it introduced an independent enforcement point between agent decision-making and system execution.

BEFORE
Agent → API → Execution

AFTER
Agent → SAILLENT → Policy evaluation → ALLOW / DENY → API → Execution

This allowed the organization to increase agent autonomy while maintaining explicit boundaries around high-impact actions.

Results

During the initial production evaluation period:

The most significant result was not the number of actions blocked. It was the location of the control:

Unauthorized agent actions were rejected before reaching the protected system.

Audit and governance

Every enforcement decision generated an auditable record containing: agent identity, tool, action, policy, policy version, decision, reason, timestamp, request context, and execution outcome.

Security teams could therefore reconstruct not only what the agent did, but also:

What the agent attempted to do, which policy evaluated it, and why the action was permitted or denied.

Policy changes were managed through the organization's existing Git-based review process, providing version history and an explicit relationship between policy changes and enforcement behavior.

The operational outcome

The bank's security architecture changed from:

"Can this identity access the payment system?"

to:

"Is this specific agent authorized to perform this specific action against this specific target under these conditions?"

That distinction became the foundation for the institution's autonomous AI security model. The objective was not to make agents incapable of acting. It was to make their authority explicit, constrained, observable, and independently enforceable.

Architecture

Untrusted input
Documents · Email · Web · Retrieval · Tool responses
        ↓
AI Agent
Reasoning · Planning · Tool selection
        ↓
SAILLENT AI Action Firewall
Identity → Inspection → Policy evaluation → Decision
        ↓
ALLOW / DENY
        ↓
APIs · MCP Tools · Databases · Infrastructure
        ↓
Execution + Audit

Key takeaway

The fintech platform did not need to prove that its AI model could never be manipulated. It needed to ensure that model manipulation could not automatically become unauthorized system execution.

The model can decide what to do. SAILLENT decides whether it gets to happen.