A test report can't tell you what an agent does on the case nobody anticipated. A new-hire mindset can.
Most of the conversation about trusting AI agents is stuck on the wrong mental model. When a vendor adds an agent to a product, or your own team brings one in, the instinct is to evaluate it like software. That's exactly why so many security teams either stall out in evaluation or deploy something they don't fully understand. And many agents won't arrive through an evaluation at all. They'll show up inside apps your employees already use, at the Workforce Edge. You can't onboard an agent you don't know is there.
‍
There's a better model. Treat an agent as a new employee, and trust stops being a test you pass and becomes a process you run. That gives you a practical set of questions, for yourself and for any vendor putting an agent into your environment: how to delegate safely, how to review early work, and how to govern over time. What follows takes each in turn, then covers what a vendor should be able to show you and what's still your job once the agent is running.
‍
When you decide to trust a piece of software, you're validating one thing: deterministic behavior under predictable conditions. Someone writes tests, defines inputs, asserts outputs, and ships when the suite is green. As a buyer, you've leaned on that process for decades. A vendor's passing test results were a reasonable proxy for how the product would behave in your environment.
‍
But it's the opposite of why you reach for an agent in the first place. You want an agent because you want the dynamic behavior you've seen from AI. You want something that handles the predictable cases and the edge cases that traditional software fails on, without you enumerating every one of them in advance. The value is in the judgment, not the determinism.
‍
So when a vendor answers, "how do we know this agent is trustworthy?" with a test report, or your own team tries to build a regression suite around a vendor's agent, they run into a wall. You can't pin down every input. You can't assert every output. And if you could, you wouldn't need an agent. You'd write a script.
‍
My advice for any security leader evaluating an agent, whether it ships inside a vendor's product or you're bringing it in yourself, is to stop thinking of it as a program and start thinking of it as a new employee.
‍
That shift sounds soft, but it changes the questions you ask, and the new questions are the right ones.
‍
One objection comes up immediately: a new employee is accountable for their work, and an agent isn't. That's true, but accountability doesn't disappear when you deploy an agent. It relocates. When you hire a person, they own the outcome, and their job depends on delivering it. When you bring on an agent, that ownership moves to you, the person who decided to put it to work. The agent won't be in the room when the task goes wrong. You will. Which means the questions you'd normally let a manager and a new hire sort out between themselves are now yours to answer directly.
‍
There are three of them, and they follow the arc of any hire: before they start, during the first weeks, and for as long as they stay. Ask each one of yourself. Then ask the vendor to show you the answer in the product.
‍
You don't hand a first-week employee the keys to production and the company credit card. You scope their work. You give them access to what they need and nothing more. You put them on tasks where a mistake is recoverable before you put them on tasks where it isn't. Agents deserve exactly the same treatment: least-privilege access, bounded scope, and a clear line between what they can do on their own and what requires a human sign-off.
‍
Nobody expects a new hire to be perfect on day one, and nobody expects to never check their work. You review the first deliverables closely. You give feedback. You watch for the gaps between what you meant and what they heard. With an agent, that means reading the actual outputs of the first operational runs, not just checking that the job completed. Look for the moments where it exercised judgment rather than followed a rule. Did it make the decisions you would have made? Where it deviated, was the deviation reasonable? This is where most of your trust gets built, and it's work you can't skip.
‍
Trust isn't a one-time grant. For employees, you have one-on-ones, performance reviews, audit trails, and a manager who notices when something drifts. Agents need an equivalent: ongoing visibility into what they're doing, what they're accessing, and whether their behavior is changing over time. The model underneath them will change. The data they operate on will change. Your expectations will change. Governance is how you keep all three aligned.
‍
If the new-hire frame is right, it changes what you ask a vendor for. A passing test report tells you the agent worked on the cases someone anticipated. It doesn't tell you what the agent does on the case nobody anticipated, and that's the case you bought an agent for.
‍
So the evidence to ask for looks like what you'd want from a new hire's first month: what they did, whether their judgment held up, and whether you can safely give them more room. Whatever the product and whoever built the agent, ask to see three things before you hand it real access:
‍
Trust that expands over time, not all at once. Delegation is a progression. Ask whether the product lets you start with a narrow scope and a human in the loop, then widen both as the agent's judgment proves consistent with yours.
‍
A supervised training period. You wouldn't let a new employee operate unsupervised in their first week, no matter how strong their resume. The same holds here. Ask whether there's an explicit onboarding mode, where the agent's judgment calls are surfaced to you for validation before they take effect. You read the decision, confirm or correct it, and decide when it's ready for more.
‍
A detailed record of what it did. Not a completion status. A log of every action the agent took, the inputs it acted on, and, most importantly, the calls where it had to interpret rather than execute. Those decision points are where an agent earns or loses your trust, and if you can't see them, you're trusting blind.
‍
Hold every vendor that puts an agent in front of you to these three, and ask them to show it rather than describe it. A product that can't expose the agent's reasoning, can't give you a structured way to supervise it early, and can't let you extend autonomy at a pace you control is asking you to trust a black box on faith. If a vendor can't show you how their agent is onboarded, that tells you how seriously they take the question.
‍
The most important benefit is consistency on mundane work. In most organizations, the hardest thing to get from a person is the same careful result on the same boring task, every time, indefinitely. Humans get bored. They cut corners on the hundredth repetition, and eventually they leave, and you start over with someone new.
‍
An agent doesn't get bored or cut corners, and it doesn't leave. It won't stay perfectly consistent on its own, since models and data shift, but that's a drift problem you can see and correct. A tired analyst skipping steps is one you usually find out about after the fact.
‍
For security teams, that's where the value is. The repetitive checks are the ones that slip when a team is stretched, and they slip quietly, because nobody's watching the work that's supposed to be routine. Consistency is also what lets you build a process on top of an agent's output instead of wondering whether this week's result is comparable to last week's. That only holds if the agent was onboarded properly. Skip the onboarding and you get the speed without the reliability. Do it, and the boring work stops being where things go wrong.
‍
The product has to give you the visibility and the controls. You have to use them in three important ways:
‍
That's how you build trust in a new employee. It's how you should build trust in an agent, too, with one difference: this time, you're the one whose name is on the work.
‍
That's the standard we built Nudge Security's AI agents to meet. Whichever vendor you're evaluating, including us, ask to see staged autonomy, a supervised observe mode, and a full decision log in the product.
