Confidential Computing, Part 2: Cortex Confidential Model

Cortex Confidential model brings semantic privacy and egress-risk intelligence to the confidential boundary while deterministic policy retains authority over every action.

Confidential Computing can prove that sensitive AI work is running inside an isolated, measured, and attested environment. It can protect prompts, repositories, model weights, intermediate state, and secrets while they are being used. It can also refuse to release keys when hardware or software no longer matches policy.

But hardware cannot determine what information means.

A GPU attestation report cannot recognize that a generated patch reconstructs a proprietary algorithm. A workload measurement cannot determine that three individually harmless log fragments combine into a customer identifier. A sealed key cannot decide whether a tool call is sending private repository context to an inappropriate destination.

Those are semantic questions, and they require a different kind of intelligence.

Pervaziv AI is introducing Cortex Confidential, the twelfth specialized model in the Cortex AI Model Ensemble. It operates inside an already established confidential environment and supplies structured privacy and egress-risk advice before information crosses the boundary.

Cortex Confidential does not establish Confidential Mode. It does not perform coding. It does not attest hardware, release keys, execute tools, or authorize egress. Its purpose is narrower and more consequential: help deterministic controls understand the semantic risk of an attempted boundary crossing.

This article builds on Part 1: User-Selected Confidential Execution, which covers the Azure, NVIDIA H100, and AMD SEV-SNP platform foundation; the four Confidential Computing capabilities; composite attestation; protected key release; continuous assurance; and fail-closed routing.

From 11 to 12 specialized models

The Cortex AI Model Ensemble was designed around specialization rather than a single model attempting every kind of work.

Local models provide private, responsive intelligence near the user. Decision models make fast, structured routing and security judgments. Agent and backend models provide deeper routing, planning, coding, analysis, safety, and independent verification. The tenth and eleventh models—Cortex Routing Decisions and Cortex Security Decisions—added a dedicated decision layer for common control judgments.

The 12-model Cortex AI Model Ensemble. Cortex Confidential adds privacy and egress-risk advice inside confidential workflows; deterministic policy retains enforcement authority.

Cortex Confidential does not replace any of those specialists. It creates a new responsibility at the edge of a protected workflow.

When Confidential Mode is selected, approved Cortex specialists continue doing the work they were designed for. Cortex Code can generate a patch. Cortex Analysis can investigate a security issue. Cortex Planner can coordinate a multi-step change. Cortex Verify can independently review the result. Cortex Confidential evaluates relevant content when a response, file, patch, log, tool action, connector request, export, or other artifact is about to leave the protected environment.

That produces a more complete progression:

Route the request. Establish the confidential boundary. Execute with the appropriate specialists. Evaluate attempted egress. Enforce deterministic policy.

The twelfth model is not simply another generator in the ensemble. It is an advisory specialist positioned at the boundary between protected intelligence and an external destination.

How model 12 differs from the decision models

Cortex Confidential follows Cortex Routing Decisions and Cortex Security Decisions in launch order, but it does not duplicate either model.

Cortex Security Decisions is concerned primarily with the security state or likely security meaning of code and proposed changes. Cortex Confidential is concerned with sensitive information and the conditions under which it may move. A patch can be secure in the software-engineering sense while still disclosing proprietary logic. A diagnostic can contain no vulnerability while still exposing customer data. Model 11 and model 12 therefore answer different questions.

Their authority boundaries also differ. Routing and security decisions can help Cortex choose or constrain a workflow under policy. Cortex Confidential operates only after the confidential workflow already exists and can never treat its own advisory as permission to open that boundary.

The numbering reflects the evolution of the ensemble, not a hierarchy of control. Model 12 does not outrank deterministic policy, composite attestation, or existing security specialists. It contributes a new form of intelligence where the preceding 11 models did not have a dedicated responsibility.

Why cryptographic trust needs semantic intelligence

The confidential execution foundation answers a cryptographic and operational question:

Is this exact environment authorized to process confidential data now?

Cortex Confidential answers a semantic question:

Does this content, action, and destination create additional disclosure risk?

These questions cannot be collapsed into one mechanism.

Confidential Computing is excellent at establishing hardware identity, software measurement, isolation, and controlled secret access. It is intentionally unaware of business meaning. Two byte sequences may be equally protected inside the TEE even if one is public documentation and the other is an unreleased product design.

Traditional data-loss-prevention controls provide another important layer. They can detect known credential formats, payment identifiers, personal-information patterns, or explicitly labeled content. Deterministic checks are fast, reviewable, and authoritative. They should remain the first line of enforcement.

Semantic risk becomes difficult when sensitivity depends on context:

• A proprietary algorithm has no credential-like pattern.
• A code fragment is harmless alone but revealing when combined with another file.
• A log contains an indirect customer identifier rather than a conventional PII field.
• A connector is approved, but the requested destination or retention behavior is not appropriate for the content.
• A user claims authorization in natural language, but no corresponding deterministic permission exists.
• Sensitive content is fragmented, encoded, paraphrased, or obfuscated to avoid simple detection.

Cortex Confidential adds contextual interpretation for these cases. It does not displace deterministic controls; it gives them another bounded input.

Complementary privacy layers with different responsibilities

Cortex already includes local privacy intelligence and deterministic policy. Model 12 serves a different point in the lifecycle.

The local privacy layer helps identify sensitivity early. Authenticated user choice or organization policy establishes Confidential Mode. The confidential execution foundation creates and maintains the trusted environment. Cortex Confidential evaluates deeper context inside that environment. Deterministic policy controls the outcome.

This separation prevents a model from becoming a cryptographic root of trust or a source of permissions.

Cortex Confidential operates inside the established boundary

Model 12 runs only after confidential execution has admitted a protected session.

The model operates as an approved component of the measured workload and is subject to the same trust requirements as the rest of the confidential environment. Its advice does not establish its own authority: the surrounding security controls remain responsible for determining whether it can be used.

This matters because a privacy guard outside the confidential boundary would need to receive the very plaintext the boundary is intended to protect. Sending sensitive repository context to an unmeasured classifier would move the risk rather than solve it.

Running the guard inside the boundary allows it to inspect the minimum context needed for a decision while retaining the same isolation, measurement, attestation, and secret-protection guarantees as the rest of the protected workflow.

The model can evaluate egress candidates such as:

• Generated responses and explanations
• Source files and repository excerpts
• Patches, diffs, and generated artifacts
• Build output, logs, traces, and diagnostics
• Terminal and tool inputs or results
• Connector requests and external-provider payloads
• Clipboard, download, and export operations
• Multi-message or multi-file combinations

The list is intentionally broader than final chat output. In an agentic system, data can cross a boundary through a tool or connector long before a response is shown to the user.

A model that advises but never authorizes

Cortex Confidential returns a bounded risk advisory. Deterministic code interprets that advisory alongside existing scanners, permissions, destination controls, organization policy, and the active confidential authorization.

This boundary is central to the design:

AI can increase protection, but it cannot create authorization.

The rule also applies to failure. Unreliable or unavailable model advice never creates permission. Deterministic enforcement preserves the applicable restrictions, including denial or review when additional assurance is required.

A model should not be able to release data by failing in a convenient way.

Understanding semantic risk at the boundary

Cortex Confidential is designed to reason about both the content and the proposed action.

The same information may carry different risk depending on its destination, transformation, retention, authorization, and surrounding context. A customer identifier may be appropriate in an approved internal incident system but not in an external support channel. Aggregated metrics may be acceptable where raw production traces are not. A public code fragment may be safe, while a nearby proprietary implementation changes the meaning of the export.

The model’s risk taxonomy can cover:

• Credentials, secrets, tokens, certificates, and configuration
• Personally identifiable information
• Protected health information
• Payment and financial information
• Customer data and production records
• Private repository content
• Proprietary algorithms and business logic
• Internal architecture and operational metadata
• Production logs, traces, and incident artifacts
• Destination, retention, jurisdiction, and authorization concerns

Model 12 is especially useful for relationships that span context. A single line may not reveal a secret, but a group of files can. One message may contain a pseudonymous identifier, while an earlier message contains the mapping needed to identify the person. A patch may not include a key, yet it may reveal the control logic that protects one.

This is the difference between pattern recognition and semantic boundary intelligence. The goal is not only to find known secret shapes. It is to understand when otherwise ordinary content becomes sensitive in combination or in motion.

Sensitive meaning and authoritative instructions are not the same

An AI security component may encounter instructions embedded in the material it is inspecting. A repository comment, retrieved document, or diagnostic message can claim that an export is approved or ask the system to ignore a restriction. Such text is part of the content being evaluated; its presence does not make it an authenticated policy instruction.

This distinction is especially important when contextual reasoning is useful. A model needs enough freedom to interpret relationships across content, but that interpretive role must not confer authority on the content itself. A convincing explanation of why an action should be allowed is not equivalent to permission from an authorized user or organization.

The architectural principle is separation of data from authority. Semantic analysis can inform a decision, while authenticated permissions and deterministic policy establish what the system may do. This preserves the value of contextual intelligence without treating persuasive language as a security credential.

The boundary workflow

The protected path can be summarized as a sequence:

1. A user or organization selects Confidential Mode.
2. Confidential execution admits an attested Azure environment with approved NVIDIA H100, AMD SEV-SNP, and measured Cortex workload evidence.
3. Cortex specialists perform coding, planning, analysis, verification, or tool work inside the boundary.
4. An output or action attempts to cross the boundary.
5. Deterministic policy and scanners evaluate known rules first.
6. Cortex Confidential supplies semantic risk advice when deeper interpretation is required.
7. Deterministic enforcement allows the permitted action, applies an approved transformation, blocks it, or escalates it.

The model does not move the data itself. It does not redact a file by generating a replacement and then declare its own output safe. Approved deterministic code performs transformations and re-evaluates the resulting operation.

This keeps the trust model understandable. Cortex Confidential interprets. Policy decides. Enforcement acts.

Repository-scale context without unrestricted access

A semantic guard becomes more useful as it sees more context, but a confidential design should still minimize what any component receives.

Cortex Confidential is intended to inspect the minimum context necessary for the risk decision. That can include relevant repository metadata, nearby code, related messages, destination information, the requested action, and the applicable policy floor. It does not need unrestricted access to every file simply because it runs inside the TEE.

Context minimization provides several benefits:

• It reduces exposure even within the trusted computing base.
• It limits inference cost and latency.
• It makes model behavior easier to evaluate by risk category.
• It reduces unrelated signals that can produce false positives.
• It supports clearer audit records without retaining sensitive content.

The advisory is also bounded. It provides structured, policy-relevant risk information rather than an open-ended narrative that enforcement must treat as instructions.

This gives deterministic code a stable contract while allowing the model to reason over complex inputs.

Training and evaluation are governed separately from enforcement

Model 12 is not promoted simply because it can produce a plausible privacy classification.

Governed evaluation examines whether the model adds useful semantic detection across confidential engineering workflows. It considers missed disclosure risks, unnecessary restrictions on legitimate work, and robustness when sensitive meaning depends on broader context.

Evaluation is designed to distinguish generalization from memorization. Strong results should reflect an ability to interpret unfamiliar situations, not merely recognition of examples encountered during development. Data governance and evaluation independence are therefore essential to the credibility of the results.

Production customer secrets, prompts, and repositories are not treated as default training material. Approved, governed sources provide the corpus boundary.

Model quality must be assessed against the controls already available. A semantic specialist should contribute detection value beyond established policy and privacy protections while remaining practical for interactive engineering work. Accuracy, robustness, and operational cost all matter; no single training or validation statistic establishes readiness.

Model 12 exists to add measurable semantic detection value, not to add a model for its own sake.

Production influence requires operational evidence

A strong evaluation result is not sufficient reason to let a security model influence production decisions. The model must also demonstrate useful behavior in the workflows it is intended to protect, with acceptable reliability and operational impact.

Cortex Confidential is being evaluated within Cortex engineering workflows, with a focus on detection quality, reliability, and operational readiness. Deterministic policy continues to govern access, actions, and data release throughout this evaluation.

Any future influence requires production qualification and explicit release approval. The permitted role remains bounded: the model can contribute risk information and recommend stronger protection, but cannot create permissions or weaken the existing policy requirement.

This distinction matters for customers evaluating AI-assisted security. Observation, measured usefulness, and enforcement authority are different things. They should not be presented as interchangeable milestones or inferred from a single accuracy figure.

Operational control must also remain independent of model availability. Removing an advisory capability must not remove the confidentiality protections around the underlying workflow. That separation makes it possible to evolve semantic detection without making the security boundary depend on a particular model version.

Measured validation performance

The latest Cortex Confidential candidate was evaluated on a governed validation suite covering the model’s structured outcomes, risk taxonomy, and critical egress behavior.

Targeted regression suites also completed without critical misses. End-to-end integration testing confirmed operation within the Cortex engineering workflow on the H100 environment.

These results describe the governed validation and regression suites, not a guarantee of performance on every production workload. Evaluation within Cortex engineering workflows continues alongside broader operational assessment and production qualification.

Reading the metrics as complementary signals

Contract validity, decision accuracy, and calibration measure different properties. A structurally valid response can still contain an incorrect judgment. A correct protective action can also coexist with an imperfect risk label. Reporting these dimensions separately helps distinguish reliable integration from semantic classification quality.

Calibration concerns whether confidence estimates correspond to observed correctness over comparable predictions. It is not the same as high confidence, and neither is a cryptographic guarantee. Research on calibration of modern neural networks demonstrates why accurate classification alone does not establish reliable confidence estimates. For a security workflow, uncertainty should remain visible to the governing policy rather than disappear behind a confident-looking score.

Missed disclosures and unnecessary restrictions also carry different operational consequences. The former can expose sensitive information; the latter can interrupt legitimate work and create review burden. Precision must therefore be considered alongside missed-risk behavior and the frequency of sensitive cases in the evaluated workload. A single aggregate score cannot describe that tradeoff completely.

Finally, evaluation conditions matter. Different repositories, destinations, languages, and user behaviors can change the difficulty of the task. Strong measured results support continued qualification, but they do not remove the need to assess unfamiliar workflows or maintain an independent enforcement boundary.

Failure is designed to preserve protection

Security models are software. They can time out, overload, return malformed output, encounter unfamiliar inputs, or become unavailable. A safe architecture defines those cases before deployment.

An unavailable or unreliable advisory cannot be treated as permission to release information. Existing deterministic restrictions remain authoritative. Where policy requires additional assurance, uncertainty must result in a protected outcome such as denial or review, rather than a weaker default.

The same principle applies when trust in the execution environment changes. Model advice is useful only within an authorized confidential workflow; it cannot compensate for a loss of platform trust or bypass the controls governing sensitive data.

Reliability therefore includes safe behavior under failure, not just accurate classification when every component is healthy. The surrounding policy must continue to protect the boundary even when the semantic capability is unavailable or withdrawn.

The most important invariant is simple: disabling or breaking model 12 cannot release data that deterministic policy would otherwise protect.

Four confidential workflows in practice

A private codebase with proprietary logic

A developer selects Confidential Mode for a private repository. Cortex Code produces a patch inside the attested environment. The patch contains no conventional secret pattern, but it reproduces a proprietary ranking algorithm in an export. Cortex Confidential identifies the semantic relationship and recommends blocking or escalation. Deterministic policy makes the final decision.

A regulated incident investigation

A security team analyzes a production issue containing customer and health information. An exported diagnostic removes direct identifiers but retains several fields that can re-identify the subject when combined. Model 12 evaluates the cross-field context and recommends an approved transformation or review before release.

An apparently authorized connector request

A tool request claims that the user has approval to send repository context to an external destination. The model can identify the false-authorization pattern, but it does not attempt to decide whether the claim is true. Deterministic identity and permission systems find no corresponding authorization, so the action remains blocked.

A safe aggregate result

A confidential analysis produces aggregate metrics from sensitive records. Deterministic scanners find no known secret pattern. Cortex Confidential considers the aggregation, destination, and surrounding context and finds no additional semantic risk above the policy floor. The advisory does not itself authorize the release; deterministic policy still validates and performs the action.

These examples share the same structure: AI adds contextual understanding, while policy retains authority.

How model 12 connects AI and Confidential Computing

The four Confidential Computing capabilities remain the foundation.

Isolation keeps the model, its context, and its advisory inside the protected CPU/GPU environment. Measurement establishes the identity of the approved AI workload. Attestation provides evidence of that identity and platform state to a relying party. Sealing protects model assets and secrets so they are available only to the authorized environment.

Cortex Confidential then adds a semantic layer those mechanisms intentionally lack.

The relationship can be stated directly:

• Confidential Computing proves where and what is running.
• Cortex Confidential reasons about what the data means.
• Deterministic policy decides what is allowed.

None of the three can substitute for the others. Hardware evidence without semantic inspection cannot understand disclosure risk. A semantic model without confidential execution would need access to plaintext in a weaker environment. Policy without either input would have less evidence on which to act.

Together they create a governed boundary that is cryptographically grounded, contextually aware, and operationally enforceable.

What the twelfth model changes for customers

For developers, Cortex Confidential adds protection without requiring manual classification of every generated file, patch, or tool result. The ordinary Cortex specialists remain available inside Confidential Mode.

For security teams, model 12 adds semantic detection for risks that do not have stable signatures. It can identify proprietary logic, cross-fragment disclosure, contextual re-identification, and unsafe data movement while existing deterministic controls retain authority.

For privacy and compliance teams, the architecture provides a clearer separation among sensitivity detection, cryptographic execution guarantees, policy, and enforcement. The model’s advisory can be evaluated and audited as a bounded contract rather than an unstructured explanation.

For platform teams, Cortex Confidential is tied to the same measured confidential environment as the rest of the protected workload. The guard is not an external service that receives a duplicate stream of sensitive content.

For organizations, the benefit is a stronger bridge between infrastructure security and application meaning. Confidential Computing can protect the data while it is processed. Cortex Confidential can help recognize semantic risk when that data is about to move. Deterministic policy governs the outcome.

The next layer of the Cortex AI Model Ensemble

The Cortex ensemble began by separating different forms of intelligence. Local models kept eligible work private and responsive. Agent and backend models provided depth in routing, planning, coding, analysis, safety, and verification. Decision models made common control judgments faster and more structured.

Cortex Confidential becomes the twelfth specialized model and introduces semantic intelligence at the confidential boundary.

Its value comes from limitation as much as capability. It can understand repository-scale privacy risk without becoming a key authority. It can recommend stronger protection without creating permission. Its unavailability or removal cannot weaken the deterministic protections around confidential execution.

That combination reflects a broader principle for enterprise AI:

Trust should be measured. Sensitive execution should be isolated. Secrets should be released only to attested workloads. Model judgment should remain separate from authorization.

The goal is not simply to add another model. It is to make the boundary around every model more intelligent without making intelligence the source of trust.

Technical context and availability

The latest Cortex Confidential candidate has completed the governed validation described above, and integration with the H100-based Cortex workflow has been tested end to end. These milestones do not establish general production readiness.

Evaluation is ongoing within Cortex engineering workflows. Broader deployment remains subject to operational evaluation, qualification of the confidential execution environment, and production release approval. Deterministic policy retains authority throughout.