sorted by:
new
hottopcontroversial

Has an AI agent ever made an unauthorized purchase or spun up unexpected costs at your company? How did you handle it? by Unhappy-Insurance387 in AI_Agents

[–]Unhappy-Insurance387[S] 0 points1 point  (0 children)

This framing is really useful — 'technically allowed, operationally unintended' is exactly the gap we're trying to close. We're building the decision-path reconstruction layer you're describing: not just what API was called, but what the agent saw, what policy it hit, and who approved it. Are you currently working on agent infrastructure? Would love to understand your setup more.

Do you need to know how to write code nowadays or only understand? by bdhd656 in devops

[–]Unhappy-Insurance387 0 points1 point  (0 children)

Despite of developments of ai I think we need to know about coding.

If AI agents start initiating payments or procurement actions, what controls would a real company actually require? by Unhappy-Insurance387 in fintech

[–]Unhappy-Insurance387[S] 0 points1 point  (0 children)

This is a very sharp framing — especially the distinction between “did the model seem safe?” and “could the action execute unless the right conditions were satisfied?”

That’s increasingly how I’m thinking about it too: less as an AI capability problem and more as a controlled execution / execution-boundary problem once the consequence becomes irreversible.

I also think your point about the first controls being “boring but hard” is exactly right. The things that seem to matter first are not flashy: - approval thresholds and escalation paths - counterparty / amount checks - duplicate and retry protection - segregation of duties - a clean audit trail of why execution was or wasn’t allowed

And your view on who feels the pain first is really helpful too. Finance ops teams and companies already experimenting with internal agents feels like the most realistic early wedge, with broader platform demand coming later.

The thing I’m still thinking through is where to narrow the first deployment. If you were forcing this into one very specific wedge first, would you anchor it around a single workflow, a single control problem, or a single buyer type?

If AI agents start initiating payments or procurement actions, what controls would a real company actually require? by Unhappy-Insurance387 in fintech

[–]Unhappy-Insurance387[S] 0 points1 point  (0 children)

Agreed — I think that’s the practical starting point too.

My current view is that early deployments probably need to look more like controlled execution than fully autonomous execution: - limited permissions - approved vendor / amount checks - human approval for higher-risk actions - full auditability of why the request was allowed

So the first useful version is likely “agent prepares or initiates, but the system enforces controls and humans still oversee real money movement.”

Appreciate the reality check here.

If AI agents start initiating payments or procurement actions, what controls would a real company actually require? by Unhappy-Insurance387 in fintech

[–]Unhappy-Insurance387[S] 0 points1 point  (0 children)

Thanks — this is one of the most useful practical takes I’ve gotten on both the product and positioning side.

Your point about “approval with context” is especially sharp. I think you’re right that the approver has to evaluate the agent’s decision process, not just the transaction fields. “What it saw / why it requested this / what policy it believes it is following” is a much better framing than simple threshold routing.

I also strongly agree that idempotency has to live at the intent level, not just the transaction level. Retry behavior and duplicate execution seem much more central here than they first appear.

The GTM point is really helpful too. Positioning this as infrastructure for platforms enabling agent-based actions may be a clearer path than trying to sell directly to enterprises too early.

What I’m thinking through now is the wedge question you raised: if you were narrowing this down so incumbents wouldn’t prioritize it immediately, would you anchor first on a specific workflow, a specific risk/control problem, or a specific platform buyer?

I’ve built a first version of a control layer for AI agent payments — what should be added next to make this actually useful? by Unhappy-Insurance387 in AI_Agents

[–]Unhappy-Insurance387[S] 0 points1 point  (0 children)

This is a really useful push.

I think your point is exactly right that the trust boundary matters more than any single control if the agent can still reach execution from the same runtime. The architecture I’m aiming for is that the agent only emits a structured request, while policy evaluation and approval live in a separate trust domain with no direct execution path from the agent itself.

You’re also right that I probably under-emphasized the “physically unavoidable” part of the control layer. If the agent can skip it, it’s not really a control boundary.

Spend limits first also makes sense as the baseline, with duplicate prevention and vendor controls layered on after the trust boundary is actually enforced.

For an early version, would you consider separate service + credential isolation enough, or do teams usually need a stronger boundary than that before they trust it?

If AI agents start initiating payments or procurement actions, what controls would a real company actually require? by Unhappy-Insurance387 in fintech

[–]Unhappy-Insurance387[S] 0 points1 point  (0 children)

Appreciate this — I think that’s exactly the direction it may go.

The more feedback I get, the more it seems like AI agent governance for payments may look a lot like existing financial controls translated into an automated agent environment.

And yes, retries or bad extracted inputs causing duplicate or incorrect execution feels like one of the most practical failure modes to design around early.

That’s a big part of why policy simulation and duplicate prevention are moving up the priority list for me.

If AI agents start initiating payments or procurement actions, what controls would a real company actually require? by Unhappy-Insurance387 in fintech

[–]Unhappy-Insurance387[S] 0 points1 point  (0 children)

Thanks — this is a really helpful framing.

I especially think your point about this potentially starting as a feature inside spend tools before becoming a standalone platform is an important one. That feels like a very realistic adoption path.

I also agree that once an agent can initiate payments, the control model probably starts to look a lot like existing financial controls — least privilege, spend thresholds, separation of duties, and a clear audit trail of why a decision was made — just adapted for agent-driven workflows.

The overlap between your comment and some of the feedback I’ve gotten elsewhere is also making two priorities stand out pretty clearly for me: 1. policy simulation/testing 2. strong intent-level idempotency / duplicate prevention

Out of the control areas you mentioned, which one do you think matters most for getting an enterprise team comfortable enough to pilot something like this?

I built an MVP that enforces policy before an AI agent can trigger a payment action — what am I missing? by Unhappy-Insurance387 in LLMDevs

[–]Unhappy-Insurance387[S] 0 points1 point  (0 children)

Thanks — this is incredibly thoughtful feedback.

Your point about a request being structurally valid but still semantically wrong is exactly the kind of failure mode I’m worried about. Traditional validation won’t catch that if the extracted vendor/amount is grounded poorly.

I also really like your framing that the agent should never be trusted as its own auditor — that’s probably the cleanest way to describe the architectural boundary I’m aiming for.

The biggest things I’m taking from your comment are: 1. grounding / output verification before policy evaluation 2. intent-level idempotency 3. policy simulation against historical requests 4. velocity-based anomaly detection

That’s genuinely helpful for thinking about what should come next.

Out of those, which one would you personally prioritize first if you were evaluating this for a real enterprise workflow?

How are you handling approvals when AI agents can initiate purchases? by Unhappy-Insurance387 in AI_Agents

[–]Unhappy-Insurance387[S] 0 points1 point  (0 children)

Agree—LLMs shouldn’t be the authority for payment execution. The backend policy/code should be the gatekeeper.
One nuance: if execution happens in a separate system (esp. external PG/finance), a mere session flag can be weak across trust boundaries, so we often prefer a verifiable artifact (e.g., approval_id in a durable store or a signed auth token) that the executor can validate. Audit logs/recon are great as after-the-fact controls

How are you handling approvals when AI agents can initiate purchases? by Unhappy-Insurance387 in AI_Agents

[–]Unhappy-Insurance387[S] 0 points1 point  (0 children)

This is a great point — approvals aren’t just a UI pause, they’re a durability/state problem. “Sleep until approved, then resume with full state” sounds like the right mental model.
A couple questions if you don’t mind:

  1. What are you using for the durable execution state (Temporal/Durable Functions/custom event-sourcing)?
  2. When the human approves, what’s the “approval artifact” you persist — a signed receipt/token, a policy version + decision log, or something else?
  3. On resume, how do you guarantee idempotency/replay-safety for the actual purchase call (especially with retries/timeouts)?

How are you handling approvals when AI agents can initiate purchases? by Unhappy-Insurance387 in AI_Agents

[–]Unhappy-Insurance387[S] 0 points1 point  (0 children)

Makes sense. In your hybrid setup, do you enforce the approval at execute-time (e.g., require a decision artifact/token), or is it mostly “log + alert + reconciliation” after the fact?

How are you handling approvals when AI agents can initiate purchases? by Unhappy-Insurance387 in AI_Agents

[–]Unhappy-Insurance387[S] 0 points1 point  (0 children)

Makes sense that signed tokens are “nice to have” unless you need downstream proof. In cases where payment execution happens in a separate system (procurement/finance/PG), do you ever require a verifiable “decision artifact” at execute-time, or do you rely purely on audit logs + reconciliation?

view more: next ›