Confidential technical resources for evaluating First Recon AI. Access is provided by your First Recon contact.
One governed control point sits between every AI interaction and every model. This page walks through the supporting evidence in one scroll, beginning with the reference views, then the security architecture, the data model and flows, AI providers, and identity.
Every diagram in the Solution Center also appears in the Diagram gallery, where you can find specific figures without searching page by page.Open the Diagram gallery
These three reference views show where First Recon AI sits in your architecture, how a governed AI interaction moves through the platform, and how identity, knowledge, SIEM, provider, and policy integrations connect into the governed stack.
How every governed interaction is decided before it reaches a model, from the one control point through the four runtime functions to the posture when something fails.
Every AI interaction, whether it starts in the browser workspace, desktop app, the endpoint, or an agent tool call routes through the same control point before it reaches a model. That is where authentication, routing, request normalization, and rate limiting happen before runtime policies take over. Coverage breaks down when teams create a second, ungoverned path.
Behind the control point, the AI Security Runtime™ runs four functions inline on each interaction. Detection is a composed scan rather than a single check. Interactions are read by meaning and intent, not pattern matching alone; independent scans must agree before anything releases, and deterministic policy makes the final call. Every decision is written to a sealed audit ledger as it happens.
Sees each interaction as it happens, reading who or what is acting, what data it carries, which model it is headed to, and where the response goes next. Every interaction on the governed path, not a sample.
Classifies the data an interaction carries and judges the request itself, catching sensitive data, prompt injection and jailbreaks, and policy violations in real time. The same string can read differently by actor, destination, and context.
Acts inline, before a model is reached. The call is allow, redact in place, hold for human review, or block; for agents it lands at tool calls and handoffs, with approval gates where an action would execute. What each decision does is on Data protection.
Records every decision as a sealed, metadata-only receipt naming the surface, actor, detection class, policy and version, and action taken. Raw content is not retained as evidence. Receipts export to your SIEM; the mechanics are on Integrations.
| Path | Posture | The detail |
|---|---|---|
| Primary policy check | Fail-closed | An unhandled error blocks the interaction rather than waving it through; an earlier fail-open option has been removed from the decision path |
| Deep semantic tier | Escalation, not a gate | Deeper semantic analysis layers on top of that baseline; the runtime decides per interaction whether to wait for it or to analyze immediately after |
| Unconfigured tenant | Proceeds today | With no policy configured and no findings from the faster checks, there is no policy to enforce |
Detection and enforcement run inline, in the decision path, at speeds intended for interactive use. The decision is made before the interaction proceeds, not by a sidecar reviewing a copy after the fact. Added latency depends on surface, deployment option, and traffic profile.
Where the trust boundary sits, what crosses it, and what stays inside the tenant-isolated governed data plane.
Model providers sit outside the trust boundary. First Recon governs the path to a model, enforcing policy on what reaches it and what comes back; it does not operate the models themselves. Only content the runtime has judged and allowed, or its redacted version, crosses; decision logic, policy configuration, and the underlying evidence do not. Your knowledge, logs, and evidence live inside the boundary, in a tenant-isolated governed data plane. Enterprise sources sync through a permission-aware connector (Integrations), and decision evidence leaves for your SIEM only as sealed, metadata-only receipts.
What stays yours is knowledge, logs, and evidence in that tenant-isolated plane, whichever deployment option you choose, with policy written once and enforced on every surface. Who can see each category of data, and where keys live, is under Who can see your data on Data & residency.
Every major provider is reachable through the same governed path; model selection is a policy decision, not an integration project. Smart Select routes each request within policy, administrators choose providers and models per team, and bring-your-own-key is supported per provider.
Every model request clears two gates in sequence. The AI Security Runtime™ decision lands first (allow, redact, hold, or block); a dedicated, authenticated egress gateway built on Cloudflare AI Gateway is then the only door to the provider networks. Provider credentials, including your own keys under bring-your-own-key, live at that gateway layer and are attached at egress, never embedded in application code.
The long tail of models rides OpenRouter as an aggregation layer behind the same gateway route, with the same runtime decision, the same egress, and the same evidence; even the model catalog syncs through that path. Speech and image generation clear the same runtime decision; depending on the provider they leave through the same gateway or through governed provider-native endpoints.
The models below are concretely established in the product, grouped by provider. The catalog itself is dynamic. It syncs from the aggregated provider catalog through the egress gateway, and administrators choose what is enabled for which teams. Active means enabled from day one; Available means administrators can enable per tenant.
Active Enabled from day one.
Available In the gateway catalog; administrators can activate per tenant.
Review Pending verification before being quoted externally.
No models match your search.
Verified against the product catalog on July 6, 2026. Rows marked Review are pending verification before they are quoted externally. Beyond the day-one set, per-tenant availability reflects the live gateway catalog and administrator activation, not a fixed list.
Identity here spans three layers, the people your identity provider already governs, the agents that act for them, and the identity carried into every policy decision. All three follow the identity model you already run.
Access follows your identity provider. First Recon integrates for authentication and group or role mapping rather than keeping a separate identity model. Microsoft Entra ID and Okta connect over OIDC for single sign-on, each with directory sync of users and groups, and SAML 2.0 or OIDC covers any other provider you run; the identity entries in the Integration catalog carry the per-provider specifics. Policy keys off your IdP's groups and roles, so a change in your identity system governs access here too. Connecting identity is the first integration in most deployments, because policy and access both key off it.
Agents can hold credentials, chain tools, and trigger other agents at machine speed. Their actions therefore need the same identity, access, policy, and audit controls applied to people, with enforcement at execution rather than only at sign-in or agent creation. Every tool call and agent-to-agent handoff is evaluated inline with the agent, represented user, data, destination, and applicable policy attached. High-stakes actions pause for human review, and the decision record identifies the reviewer who releases them.
Policy applies across users and agents with tenant isolation, and tool connections carry scoped permissions, so a given connection only grants what it was configured to grant. Per-identity decision records export to your SIEM, where behavioral anomaly analytics run on evidence the runtime supplies. Persona and policy assignment by department, team, or role, driven from IdP group membership, is planned; treat it as forward-looking.
Identity at login grants access; identity in the decision path travels with every interaction after it. Identity is attached and the request is normalized at the control point before any policy decision, the same treatment regardless of which surface originated the interaction. From there it is one of the inputs the Security Context Graph™ ties each interaction to, alongside data classification, device, destination, history, and policy, so nothing is decided in isolation; the decision records that remain carry classifications, identities, destinations, and outcomes, never stored prompt content.