The phishing test passed. The employee still got owned.

Here's a pattern we kept seeing while building Cimento. A company runs quarterly phishing simulations. Click rates trend down. The dashboard is green. Then a real attacker calls the help desk, references an internal project by name, follows up over SMS, and walks away with a password reset. The employee who fell for it had passed every simulation that year.

Nothing about that employee was untrained. The test was just measuring the wrong thing. A single suspicious email at a random time tells you almost nothing about how someone behaves when a convincing request lands mid-workflow, from a plausible sender, under time pressure. And that's what real social engineering looks like now.

This post explains how we think about human risk from first principles, what we built as a result, and what we haven't cracked yet.

What actually creates human risk

Strip away the industry framing and human risk comes down to three variables.

The first is context. The same click means different things depending on who clicked. A finance approver acting on a payment request during close carries more exposure than an intern clicking a fake shipping notice. Role, access, and timing change the blast radius of every decision, but most awareness programs treat all employees as one population and all clicks as one event.

The second is repetition. Real attacks are rarely one message. Attackers build credibility across touches: an email to establish a pretext, a chat message to add urgency, a phone call to close. Each individual message can look reasonable. The attack lives in the sequence.

The third is delegation, and this one is new. Employees now route work through assistants, copilots, and automations. When someone connects an AI tool to their inbox and lets it draft replies, the security-relevant decision isn't just theirs anymore. A suspicious request may be read first by an assistant. A reply may be drafted before the person slows down to verify anything. The exposure is shaped by what the tool can access, what it's allowed to do, and how much the person trusts its output.

AI squeezes all three at once. It scales the attack side, because a lure that matches a target's role, tone, and current projects used to take real effort per victim and is now cheap. And it reshapes the defense side, because human judgment increasingly sits between AI-generated pressure on one side and AI-mediated work on the other. The thing you have to measure is that blended system in motion, not the employee's final click.

Why the calendar model can't keep up

The traditional program is built around a calendar: annual training, quarterly simulations, completion reports. That structure exists because it's easy to administer and easy to show an auditor. It measures activity with precision and exposure almost not at all.

We don't think training is worthless. Shared vocabulary and a reporting culture matter, and we kept both in the product. But a calendar-based program can't answer the questions a security team actually has on a Tuesday afternoon. Who is becoming riskier this month? Which workflows would an attacker get the most leverage from? Did last quarter's intervention change anything, or did it just generate completions?

Risk moves daily. Roles change, access changes, attackers change, and now the tools employees delegate to change too. A point-in-time measurement of a moving system is mostly noise.

What we built instead

Cimento is a stack with a score at the center, and every layer exists to make that score more honest.

Training stays, but as one layer, not the program. Awareness gives the workforce shared language and habits. In our model, it's also a signal source: every assignment, report, and risky interaction is evidence.

Simulation gets realistic. Instead of a single email, a Cimento campaign unfolds across touchpoints and channels, adapting. If the employee reports the first message, the scenario ends, and they get credit. If they engage, the pressure builds the way a real attacker's would: a follow-up, a channel switch, an escalation. We measure the pattern, not the click. The number we watch closest is [NEED: % of users rated low-risk by legacy single-email testing who failed a multi-turn scenario in pilot data].

Signals get pooled. We integrate with the systems that already know things about your people: HRIS for role, identity for access, MDM and security tooling for environment. This is what lets the model treat a new engineer with fresh production access differently from a tenured salesperson, even when their surface behavior looks identical.

The score is contextual and inspectable. The same behavior can be routine at one company and alarming at another, so a generic score is close to useless. Ours is grounded in your company's context and your first-party outcomes, and we made it inspectable on purpose. A security team that can't explain a score to HR or legal won't be allowed to act on it, and a score nobody acts on is a dashboard, not a control.

The score decides something. Coaching, a harder simulation path, a review, or a recommended control change. Which brings us to the part most awareness tools never built.

From score to action, without breaking trust

A risk score earns its keep when it changes what happens next, and that's also where it can do the most damage. Push too hard and you've built a surveillance program that employees route around. So we built the response side as a loop with governance welded in.

Evidence flows in continuously: behavioral events, roles and privileges, current attack exposure, workflow context, and tool and agent use. The score places people into dynamic risk groups, and membership updates as the evidence does. Someone whose behavior improves automatically reverts to a normal, low-friction posture. Nobody lives permanently on a naughty list because of one bad click in March.

The response is proportionate to impact. Low-impact actions like a nudge or a short, scenario-specific lesson fire automatically near the event that triggered them, because that's when behavior changes. Medium-impact actions like increased inspection run on pre-approved policy paths with an owner and an expiry. High-impact actions like restricting access or blocking a workflow always keep a human in the loop, with an audit trail and a rollback path. Every action can be answered by three questions: what evidence triggered it, who owns it, and what condition reverses it.

Outcomes feed back into the model. If nudges aren't reducing repeat behavior for a group, that's a signal about the intervention, not just the people.

The agent problem, honestly

The part of this we find most interesting, and the part that's earliest, is extending the model to delegated work.

Our view is simple: agent risk starts as human risk. Someone chose the tool, connected it to data, granted the permissions, and decided how much to supervise it. The agent acts with the context and authority of its human sponsor. If that person is exposed, so is everything acting on their behalf.

What ships today is the human side of that equation. What we're building next is an agent registry that maps tools back to their sponsoring employee, the delegated task, and the permission surface, so the score can reflect the pair rather than the person alone. And we'll be direct about the open problems. Detecting short-lived agents is hard. Classifying permissions consistently across tools is hard. Distinguishing a risky agent from risky human intent behind it is genuinely unsolved, and simulating agent-to-agent social engineering is research, not roadmap. We'd rather tell you that here than let a sales deck imply otherwise.

The tradeoffs we've accepted

Multi-channel simulation is powerful and legally sharp-edged. Voice and SMS tests touch personal devices, consent, and employment law in ways email never did, so we deploy those channels deliberately, usually starting with high-risk roles and regulated workflows rather than the whole company. Realism has a compliance cost, and pretending otherwise burns trust.

Contextual scoring also means we ask for more integration access than a legacy awareness tool. That's a real ask, and it's why explainability and privacy governance aren't features for us; they're the price of admission. If we can't show your legal team exactly what we ingest and why, we haven't earned the telemetry.

Where this goes

The bet behind Cimento is that the interesting question is no longer "did the employee complete training" but "is this person, in this role, with these tools, becoming more or less exposed, and did our last intervention help?" Answering that requires treating people, workflows, and the agents acting on their behalf as one system.

If you're wrestling with the same question, especially the agent half of it, we'd like to compare notes: https://cimento.ai/book-a-demo