How much do you trust AI agents?

With the advent of clawdbots, it's as if we've all lost our inhibitions and "put our lives completely in their hands."

I'm all for delegating work, but not giving them too much personal/sensitive stuff to handle.

I certainly wouldn't trust something to the extent of providing:

  • access to personal finances and operations (maybe just setting aside an amount I'm willing to lose)

  • sensitive health and biometric information (can be easily misused)

  • confidential communication with key people (secret is secret)

Are there any tasks you wouldn't give AI agents or data you wouldn't allow them to access? What would that be?

Re. finances – Yesterday I read this : Sapiom raises $15M to help AI agents buy their own tech tools – so this may be a new era when funds will go rather to Agents than to founders.

5K views

Add a comment

Replies

Best

Depends entirely on the blast radius of being wrong.

I build voice agents for small businesses. Plumbers, roofers, dentists, and law firms, so I think about this every day. The trust ladder I've landed on, from "ship it tomorrow" to "not yet":

🟢 High trust - ship it now

- Intake. Name, number, problem, urgency. The agent is literally just a smart form with a voice. Worst case: human re-asks one question on callback. Cost of failure: ~zero.

- Triage. "Is this an emergency or can it wait until Monday?" Binary routing. Easy to verify.

- FAQ deflection. Hours, address, do-you-service-my-area. Static info, static answers.

🟡 Medium trust - needs guardrails

- Booking. Fine when the agent can only book inside a pre-approved calendar window. Disaster when it confidently invents an appointment slot.

- Lead qualification. Good for "is this person in our service area." Bad for "how much should we quote them."

🔴 Low trust - not yet, maybe never

- Anything with money attached. Quoting jobs, processing payments, issuing refunds. One hallucinated number = a real customer pissed off in the real world.

- De-escalating an angry customer. The models can do this in a demo. In production, the failure mode is too expensive.

The pattern: trust scales with how cheaply you can verify the output. Intake you can verify in 5 seconds. A quote you can't verify until the truck shows up.

Curious where everyone else draws the line, especially folks running agents in customer-facing roles. What's the highest-stakes task you've actually let an agent own end-to-end?

(Wrote up the after-hours intake pattern in more detail here if useful:

 Thank you for your POV, I would frame it the way that it is really individual on use-case, but we all can angry that money-related things are really sensitive to handle.

In my opinion, AI is currently incapable of replacing humans. Its ultimate limit is performing routine tasks. Today, humans should be the ones doing the thinking, and AI will then assist.

Agents are amazing for doing repetitive tasks and building slick automations, but giving them 100% trust? No way.

For me, it’s all about "delegate, but always review."

They make awesome sidekicks, but they still miss that human context and gut feeling. Leaving an AI agent on total autopilot-especially with important stuff - is just asking for trouble. A quick human check before anything goes live is a must.

Totally agree, I think part of the issue is there is no universal standard or protocol for AI agents today. Currently, guard rails or protocols stopping agents from becoming bad actors are accessible mostly to large companies/orgs and there is overall lack of a standard for individual agents.

Most current solutions are fragmented or don't solve issues end to end.

Most of the good answers here land on access controls, least privilege, isolated environments, and that's the right layer for security. The part that gets less attention is that trust in an agent should live in the policy, not in the person operating it that day. If the rule for what an agent can touch depends on whoever happens to be tired or in a hurry that afternoon, the system was never really trustworthy to begin with. Worth designing for the operator having an off day, not just the agent having one.

 But to design something like that is not easy at first :)

i trust an agent as far as i can audit it. same rule as any junior teammate.

what i actually check before letting one loose. can i see what it did after the fact. can i roll it back. can it explain its choice in one sentence to a non technical person. if any of those three is no i keep it read only.

the agents that scare me are the ones with silent memory. they build up a shape of your workflow over weeks and then one decision reflects a pattern you never signed off on. trust is not about intelligence. its about consent of record.

 I think that agents are faster than us, and they sometimes do not ask for our confirmation; they just do the thing :D And we need to save ourselves from disaster caused by them later :D

Financial write access is exactly where I get twitchy too ,happy to let an agent draft, research, review code, even talk to clients on my behalf. Where I stop is anything that can move money or release deliverables with zero human checkpoint in the loop.

Running into this directly right now, actually building a payment gated portal where "release the files to the client" is deliberately kept as a manual click. Not because an agent couldn't technically do it, but because that's the one moment a client wants to know a person made the call, not a script.

The Sapiom angle is interesting though once agents hold their own spending budgets, the question stops being "what can it read" and becomes "how much am I okay with it losing." Different risk entirely.

Where do people draw the line on write access specifically? Read-only feels fine almost everywhere for me it's write/execute that makes me nervous.

 Can I set a specific budget that is allocated for agent manipulation and the rest remains untouched?

I trust an agent exactly as far as it can prove what it did, and not one step further.

We build an agent that submits job applications on the employer's real hiring form, and the thing that took longest was not the filling. It was refusing every signal that only looked like proof: our own click, an HTTP 200, our own database row saying submitted, a page that resembled a thank-you. All four are read-backs of our own input, and all four are wrong often enough to matter.

So the rule we landed on: an agent is trustworthy when its success condition is produced by the other side, not by itself. Everything else is a demo.

 to be honest, an AI agent should first ask me for permission to do the step. I do not like the idea that they would do anything without my own permission. :)

This hits close to home because I'm building a dating app right now, and AI trust is literally the core tension we navigate every day.

The irony: In dating, people WANT AI help finding compatible matches (saves time, surfaces people you'd never find manually), but they're terrified of the same AI "knowing too much" about their romantic preferences and behavior patterns.

What I've learned:

  • Users trust AI more when it shows its work. "We matched you because you both prioritize communication style over looks" is way more accepted than a mystery algorithm

  • - Transparency about what data trains the model matters enormously

  • - People draw hard lines around conversation content - they want AI to learn from their swiping patterns, but reading actual messages feels invasive

The counterintuitive thing? Video-based matching actually builds MORE trust in AI than photo-based, because users can see the AI is learning from authentic self-presentation rather than curated profile pics.

@Nika Curious if you see a difference in trust levels for AI that assists decisions vs. AI that makes decisions autonomously? In dating, people want recommendations but absolutely want final say.

I'm curious - is there anyone allowing AI agents to make any purchases >$100 on behalf of themselves? I mean except for those who are experimenting or living on the bleeding edge of tech.

First
Previous
•••
131415
•••
Next