AI models that make security decisions are moving into workflows

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cato Networks's blog post: Jev is a decision-oriented AI model that turns event state into probabilistic security judgments instead of conversational text.

Why it matters: It matters because security teams will need to govern where AI makes embedded decisions, what data it consumes and how downstream controls constrain those outputs across IAM, SOC and workflow environments.

Context

Traditional LLMs are built to generate language, not to produce bounded operational decisions. That creates a governance gap when the output needs to drive triage, containment or workflow selection, because security teams need auditable decision criteria rather than open-ended prose.

This article is really about the control problem created when AI moves inside applications and security pipelines. The identity and access angle is material because those decisions can be tied to user sessions, device trust, data access and downstream authorisation in the same flow.

Key questions

Q: How should security teams govern AI models that can call tools and access data?

A: Security teams should govern AI models as non-human identities with named owners, limited scope, short-lived credentials, and continuous authorization. The critical shift is to treat every tool call, data read, and update path as a privileged action that can be logged, revalidated, and revoked. Without that discipline, model risk becomes identity risk.

Q: Why does embedded AI in SaaS create a governance gap?

A: Embedded AI creates a governance gap because authenticated access to an application does not reveal how that application will use the data it receives. A user may believe they are simply uploading content, while the platform may store it, train on it, or redistribute it. That turns data handling into an identity and policy problem.

Q: How can organisations use probabilistic AI outputs without losing control?

A: Use the model to score risk or recommend a state, then map each outcome to fixed policy and workflow rules. That keeps enforcement deterministic while still benefiting from AI judgment. The model narrows options, but the control plane decides what is permitted.

Q: How should security teams secure AI agents before they are embedded into business workflows?

A: Security teams should treat AI agents as a distinct identity and access problem, not just an application feature. The first step is to inventory agent activity, define allowed actions, and constrain access to only the data and systems each agent needs. Governance should include monitoring, policy enforcement, and review of agent decisions so unintended actions are detected early.

Technical breakdown

How decision models differ from conversational LLMs

A decision model takes structured state, a defined set of questions and a constrained output schema, then returns probabilistic judgments rather than free-form text. That changes the operational use case completely. Instead of asking a model to explain itself after the fact, teams can ask whether an event is suspicious, whether credential compromise is likely, or whether a response should be contained. The architectural shift is from language generation to classification and decision support, which is closer to a scoring engine than a chat interface. The security value comes from bounded outputs, but the governance burden shifts to the quality of inputs, thresholds and downstream action mapping.

Practical implication: Treat decision models as control inputs, not as analysts, and define the allowed response states before deployment.

Why embedded AI creates a hidden governance surface

When AI is embedded in APIs, workflows and applications, the model disappears into ordinary business logic. Users may never see a chatbot interface, but the system is still making decisions that affect containment, review routing or access handling. That makes discovery harder than with standalone AI tools because monitoring only obvious chat services misses the broader use of model calls inside production systems. From a governance perspective, the problem is not just model risk. It is also exposure of prompts, state, inference paths and the business decisions those outputs trigger. Organisations need inventory, policy and auditability at the integration layer, not only the user interface layer. See the LLM Security Guide.

Practical implication: Inventory model use in business workflows and tie each embedded decision point to an accountable owner and audit trail.

How probabilistic outputs should be paired with deterministic controls

A probabilistic judgment is useful only when the surrounding control plane knows what to do with it. A high-confidence containment recommendation, for example, should map to fixed enforcement logic, while a lower-confidence result may route to human review. This is the right separation of duties for AI in security operations. The model handles semantic judgment, but policy engines, workflow rules and access controls decide what actions are permitted. That separation matters because it prevents the model from becoming an unbounded actor. In practice, the model should narrow options, while deterministic controls enforce the actual response boundary.

Practical implication: Use policy thresholds and workflow rules to convert model confidence into controlled actions rather than direct execution.

NHI Mgmt Group analysis

Decision-centric AI will matter more than chat-centric AI in security operations. Security teams do not need every model to write a report. They need models that can turn noisy state into bounded operational judgments such as investigate, contain or close. That makes the governance question much sharper because the model is now part of the decision path, not just the interface. The practitioner implication is to classify every AI decision point by the control it influences and the action it can trigger.

Embedded AI governance debt: the hidden risk is not the visible chatbot, but the model call buried inside ordinary workflows. When AI sits inside APIs and business applications, discovery based on user-facing tools misses the real attack and control surface. That creates blind spots around data flow, prompt handling, output trust and downstream enforcement. The practitioner implication is to govern model use at the workflow layer, not only at the application edge.

Probabilistic outputs only work when they are subordinated to deterministic control. A model can score likelihood and recommend action, but policy engines must decide what can actually happen. That separation is especially important where the output affects containment, access handling or escalation. The practitioner implication is to make the model advisory and keep enforcement in explicit controls, not in inferred intent.

AI-driven security decisions need identity context to be trustworthy. The article’s examples show why device state, user context and access behaviour all matter when AI evaluates risk. That is an identity problem as much as an AI problem, because the model’s judgment depends on who or what is acting, from where and with what trust posture. The practitioner implication is to bind AI decisions to verified identity and device signals before they can drive workflow changes.

Security teams should expect more AI to look like policy logic, not like chat. Once models are used to rank risk, classify events and choose workflow paths, they become part of governance architecture rather than a separate feature. That means programme owners must think about accountability, auditability and threshold design from the start. The practitioner implication is to treat embedded AI as a governed control layer and assign ownership accordingly.

What this signals

Embedded AI governance is becoming a workflow problem, not just an AI policy problem. As models move into event feeds, applications and automated decisions, the real question is whether the surrounding control plane can prove what data was used and what action followed. The programme implication is that AI inventory, audit logging and enforcement thresholds now belong in the same governance discussion.

Decision models will force identity teams to care about inference context. If an AI output can trigger containment, review or access changes, then the trustworthiness of the user, device and session inputs becomes part of the control itself. Programmes that already govern identity signals will be better placed to absorb this shift, because the model’s output is only as reliable as the context it consumes.

For practitioners

• Define decision thresholds for AI-assisted triage Map each probability band to a specific outcome such as close, review or contain, and require those mappings to be approved by the control owner.
• Inventory embedded AI across workflows and APIs Locate model calls inside applications, event pipelines and security tooling, then record what data enters the model and what actions its output can influence.
• Separate model scoring from enforcement Keep the model advisory and let deterministic policy, workflow rules and access controls perform the actual enforcement step.
• Bind AI decisions to identity and device context Require verified user, device and session signals before AI output can trigger containment, escalation or access changes.

Key takeaways

• AI decision models shift the security problem from open-ended language generation to bounded operational judgment.
• The central governance issue is not the model alone, but the way embedded AI influences workflows, APIs and response paths.
• Security teams need deterministic controls around AI outputs so that confidence scores do not become uncontrolled actions.

Related NHI Mgmt Group resources: AI Guardrails and AI Firewalls Guide · Remote Access Identity Guide · LLM Security Guide

Key terms

• Decision Model: A decision model is a system built to return structured outcomes such as labels, scores, or routes instead of generating prose. In this article’s context, it is optimised for fast, calibrated decisions on well-defined tasks, so teams can separate judgment from text generation and monitor decisions at scale.
• Embedded AI: Embedded AI is an AI feature built into an existing application rather than delivered as a separate tool. It matters because the app may already be approved, while the new model behavior changes what data is processed, retained, or sent to third parties.
• Probabilistic Output: A model result that is likely, plausible, or coherent rather than guaranteed to be correct. For security and identity teams, the important distinction is that probabilistic output can appear authoritative while still requiring contextual validation before use.
• Deterministic Controls: Deterministic controls are rules that produce predictable, repeatable outcomes for an AI agent’s actions. They remove ambiguity by enforcing predefined conditions, allowed paths, and stop points. In security testing, they help ensure the agent behaves consistently, stays within scope, and produces results that can be audited and trusted.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is built for practitioners who need to govern identities, access and AI-driven control points across real environments.