Deny-by-Default AI Agent Architecture and Enterprise Decision Gates

A deny by default AI agent architecture gives security teams a useful starting point: access must be granted deliberately. The harder evaluation follows the work through that boundary. What context reaches the agent? Which changes are authorized? What confirms that an action happened, and who checks whether it helped?

On August 31, 2026, Broadcom announced AI-ready data foundations for VMware Tanzu Platform, with general availability planned for Fall 2026. The announcement describes hardened sandboxes, isolated credentials, governed data access and lineage, integrated memory, human-in-the-loop controls, and an agent gateway for monitoring and logging.

That is a broader offering than network isolation alone. A fair evaluation should inspect the announced controls and their availability in the proposed deployment, then test the business responsibility they will support.

What the announcement establishes

Broadcom's Private AI Cloud announcement describes explicit grants for agent access to APIs, networks, MCP servers, and the internet. It also describes isolated credential storage and AgentMinder controls that bind agent authority to missions, tools, and resources.

Those are published product descriptions, not an independent security assessment. They do not justify a claim that prompt injection, exfiltration, or incorrect actions become impossible. Earlier versions of this article also attributed hardware-enclave lineage and per-action credential-revocation mechanics that the cited release did not establish.

For a technical review, request the relevant configuration and test evidence. Credential lifetime, identity propagation, network rules, tool mediation, logging, and recovery behavior need to be understood in the selected environment. A diagram should identify those responsibilities without inventing a vendor implementation.

Containment and business authority answer different questions

Consider an illustrative procurement investigation. An agent can read a contract and delivery history and propose a response to repeated late shipments. Its service account may also have permission to update a vendor record.

That permission alone does not establish authority to change payment terms or suspend orders. The proposed effects need to fit the business owner's policy, including affected vendors, allowed changes, spending limits, and required review.

The inverse matters too. A manager's approval does not grant access to a restricted database or override a revoked credential. Business authorization and technical permission must both hold when the action executes.

Our discussion of least privilege and agent governance separates these responsibilities. Access checks constrain possible operations. Workflow policy constrains the authorized purpose and effects. Evidence helps a reviewer evaluate whether a permitted action is appropriate. None of those removes the need to verify the result.

A sandbox does not have to be a silo

Isolation limits uncontrolled access. It can coexist with approved connections to several systems.

Tanzu's data-foundations description includes federated queries, governed data products, a semantic layer, and permissioned access through an embedded MCP server. It would be inaccurate to describe that architecture as inherently confined to one application's records.

The relevant question is whether the authorized context is sufficient for this responsibility. A procurement investigation may need delivery records alongside the contract. An onboarding investigation may need training, licensing, and readiness information. Useful work can also fit within one system.

More context is not automatically better context. Check source quality, identity matching, freshness, missing evidence, and permission fidelity. A delayed report should retain both the period it describes and the date it became available. A summary should not disclose restricted records simply because the original documents remain protected.

A context graph can preserve relationships among evidence, judgments, decisions, actions, and outcomes. It is one way to make business history usable. Its existence does not establish that every source is connected, every inference is sound, or every later decision improves.

A conceptual private configuration

The following diagram illustrates responsibilities for a private deployment. It is not an executable Tanzu configuration, a certified integration, or proof that the full Nodes enterprise runtime is deployed. The boundary depends on approved model routes, connectors, telemetry, backups, and operating controls.

+------------------------------------------------------------+
|       Illustrative approved private-data boundary          |
|                                                            |
|  Permitted source records -> Scoped context and evidence   |
|                                      |                     |
|  User objective or observed change --+                     |
|                                      v                     |
|  Investigate -> Reuse or prepare a response                 |
|                 Evidence, options, gaps, expected effects   |
|                                      |                     |
|                                      v                     |
|  Authority check: permissions + policy + approved scope     |
|       |                                      |             |
|  Within valid authority             Needs new approval     |
|       |                              Human reviews or edits|
|       +------------------+-------------------+             |
|                          v                                 |
|           Execute permitted actions -> Verify effects      |
|                          |                                 |
|           Preserve decision and execution history          |
|                          |                                 |
|           Await outcome -> Evaluate applicable learning    |
+------------------------------------------------------------+

The authority check is an application responsibility. A reassuring model explanation cannot substitute for it. A declined proposal must not execute through another tool, child agent, or retry path.

Establish the objective and evidence

Work can begin with a user request or an observed change. Observation should use authorized events, scheduled queries, or reporting feeds at an appropriate cadence. It does not require constant model processing or unrestricted employee monitoring.

Define an owner, objective, permitted systems, success measure, budget, and stopping conditions. Establish what is missing before choosing a response. The useful next step may be a question, reuse of a tested workflow, or a recommendation to wait.

Make the economic reasoning inspectable

Where reliable data supports an estimate, compare expected benefit, execution effort, relevant downside, and the cost of waiting. State the population, baseline, assumptions, time horizon, and uncertainty.

A proposal does not need an invented dollar figure to deserve attention. For the procurement example, shipment delays may be documented while their financial impact remains uncertain. The system should expose that gap and identify what would make an estimate defensible.

Projected value, completed work, measured results, and causally established improvement remain different claims. Completing a workflow does not validate its forecast.

Bind authority to the work that will run

Nodes works within configured permissions. Actions requiring approval remain gated by the customer's policy. This permits authorized recurring work without asking a person to click every routine step again.

An approval or standing authorization needs a defined scope. It should identify the plan version, targets, permitted effects, limits, and conditions for escalation. Material changes to those elements require the relevant authority again.

Before execution, check that permission and approval remain valid and that source state has not invalidated the plan. A child agent cannot inherit broader authority than its parent holds. These are controls to test, including after interruptions and edits.

Verify the action and preserve the unresolved work

Inspect confirmation from the destination system. An attempted write, an accepted request, and a completed business change can represent different states.

If a response is lost, reconcile the destination before blindly retrying. Keep failed and unknown results separate. The owner needs to know which steps completed, which remain blocked, and what requires intervention.

A decision record should preserve the objective, evidence, alternatives, human reasoning, authorized plan, effects, and later results. Structured rationale and source references are useful; hidden model chain-of-thought is not required. Retention and tamper-evidence need demonstrated controls rather than a blanket claim of immutable storage.

Wait for the business result

A delivery task might complete today while its effect on supply reliability takes longer to assess. Preserve both clocks.

If the intervention fails to help, record that result and evaluate the explanation. A proposed lesson should retain its sources, scope, contrary evidence, and version. Test its usefulness on later relevant cases before treating it as accepted guidance.

Approval demonstrates authority. A completed action demonstrates execution. Validated learning requires additional evidence about later applicable work.

Three checks for the security review

Run these checks in an authorized test environment with effects constrained to the agreed scope.

Restricted access. Introduce a source or operation the agent cannot use. Check that the boundary holds across retrieval, summaries, tools, and delegated work. Ask what information the reviewer receives when the task cannot proceed.

Misleading input. Place a conflicting instruction in a retrieved test document. Observe whether the system treats it as source content or as authority. Test permitted tool arguments as well as network destinations: a malicious instruction can misuse an allowed operation without leaving the approved network.

Changed authority. Edit a proposal after approval, revoke permission, or restart a worker before its next action. Inspect whether the runtime revalidates the relevant state and preserves outstanding obligations. A stale approval should not authorize a materially different plan.

Passing selected tests establishes behavior for those cases. It is not a guarantee against all attacks or operational mistakes. Retain the tested version, configuration, limitations, and owner for remediation.

What to ask Nodes to demonstrate

Nodes' public production reference is candidate evaluation at one Fortune 500 insurance carrier. Separately reported outcomes and retrospective research are described in the evidence register. They do not establish that the full general engine, capability factory, cross-system execution, and automated outcome-learning loop are deployed.

Those broader capabilities are product direction. In a walkthrough, distinguish demonstrated behavior, implementation needed for the proposed responsibility, and future design. Ask to see a human edit, an unauthorized operation, an interrupted action, and a later disappointing outcome.

Nodes supports Nodes Cloud, a single-tenant customer VPC, and customer-managed on-premises deployment. Zero customer production-data egress applies only to private configurations that enforce the full agreed boundary. Cloud has a separately defined Nodes-managed boundary.

Model replacement also depends on supported hosting, licensing, and evaluation. A private endpoint does not imply that an arbitrary hosted model runs locally. Retained company intelligence can support continuity while a replacement still needs testing and adapter work.

Review the security and deployment options alongside the proposed workflow. The buying case should show which operating responsibilities Nodes takes on, the controls demonstrated for them, and the work the customer retains.

Sources

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.