Assaf Rappaport is opening Wiz’s cloud-security graph to a new class of operator: the artificial-intelligence agent. In July 2026, Wiz made its Model Context Protocol server generally available, allowing compatible assistants and custom agents to query security context. The company has also expanded its AI security platform across infrastructure, data, access, models, agents and applications.
The appeal is immediate. Security teams face more alerts, assets and software changes than people can examine manually. An agent connected to Wiz can answer which internet-exposed workload contains sensitive data, identify the owner and draft a remediation plan. It can bring context into the tools where engineers already work.
Context can quickly become action. An agent might change a cloud policy, isolate a workload, rotate a credential or open a code fix. Rappaport must ensure that speed does not turn uncertain security findings into production outages. The platform’s value will depend on permissions, evidence and reversibility as much as on the intelligence of its models.
The graph is a strategic asset
Wiz built its platform around relationships among cloud resources, identities, vulnerabilities, data and network exposure. A vulnerability alone may be low priority; the same flaw on an exposed system with access to sensitive information can be urgent. The graph helps teams focus on combinations that create real attack paths.
Agents need exactly this kind of context. A general model can explain a vulnerability, but it does not know a company’s architecture, ownership and controls. Through a governed interface, the model can retrieve current facts and ground a recommendation in the customer’s environment.
The graph can also connect technical and business language. An executive may ask which critical services are exposed, while an engineer needs the exact resource and policy. An agent can translate between those levels if the underlying relationships are accurate and permissions are enforced.
Rappaport should resist turning the graph into an unrestricted data pool. Each query should respect the caller’s role and purpose. A developer may see risks in a service they own; a central security team may have broader visibility. Sensitive findings can themselves become attack information if exposed to the wrong agent.
MCP expands the attack surface
The Model Context Protocol standardises connections between models and tools. That can simplify integration, but it also creates pathways through which instructions, data and actions move. A malicious instruction embedded in a ticket or repository could attempt to persuade an agent to reveal findings or call an inappropriate tool.
Wiz should assume that models can be manipulated. The MCP server needs strong authentication, scoped tokens, rate limits and explicit tool definitions. Read access should be separate from write access. Customers should be able to restrict queries by project, cloud account, data class and time.
Audit logs must capture the user, agent, model, instruction context, data retrieved and action proposed. Logs should be tamper-resistant and available to customer monitoring systems. Without that chain, an organisation cannot investigate why an agent reached a conclusion or demonstrate compliance.
Versioning is also important. Security data changes continuously, and models change over time. A decision should record which graph state and policy applied. Replaying the same request later may otherwise produce a different answer with no explanation.
Read, recommend and act are different risk tiers
Wiz can structure automation in stages. Read-only agents can search findings and summarise risk. Recommendation agents can propose remediation with supporting evidence. Action agents can call cloud or development tools. Each stage requires stronger controls.
Many organisations should begin with the first two. A well-prepared recommendation can save an engineer significant time without allowing the agent to alter production. Approval can require the resource owner and security team when a change affects a critical service.
Low-risk actions may eventually run automatically. Creating a ticket, requesting an owner or applying a tested label are easier to reverse. Disabling access, deleting resources and changing network policy require tighter limits. Wiz should provide default risk classifications while allowing customers to adapt them.
Reversibility needs to be designed, not assumed. Before a change, the agent can capture current state, test dependencies and generate a rollback. It should stop if the environment differs from the plan. Post-action checks should confirm that risk declined without breaking service.
Automation quality needs measurable evidence
Agent demonstrations often show a successful path. Enterprise buyers need failure rates. Wiz should measure false prioritisation, incomplete context, unsafe proposals, approval overrides and rollback frequency. Results should be segmented by cloud, workload and action type.
Human comparison is useful but not sufficient. An agent may process more findings while creating subtle errors that appear later. Evaluation should include red-team scenarios, ambiguous ownership, stale data and conflicting policies. External researchers can help test whether instruction injection or excessive permissions bypass controls.
Customers need tools to run their own evaluations before enabling actions. A simulation mode can show what the agent would have changed across historical incidents. Policies can require a threshold of successful supervised runs before autonomy increases.
Rappaport should make safety measures part of the commercial product rather than an optional services engagement. Smaller organisations may have the least capacity to evaluate agents and the greatest temptation to automate. Secure defaults protect them and reduce systemic risk.
Google ownership increases both capability and scrutiny
Wiz completed its move into Google Cloud in March 2026 while retaining its brand and multi-cloud commitment. Access to Google’s models, threat intelligence and infrastructure can accelerate agent development. Google’s distribution can bring the tools to more enterprises.
The relationship also creates questions about neutrality. Wiz agents must identify risks in Google Cloud with the same clarity they apply to AWS and Azure. They should support models and developer tools from several providers. Customers need assurance that security context is not used to favour Google products.
Data boundaries are critical. Wiz findings contain sensitive architectural information. Google should not use customer security data to train unrelated models or inform competitive sales without explicit permission. Contracts, technical controls and auditability all need to support that promise.
Rappaport’s role is to preserve the security company’s credibility while using the parent’s resources. The agent platform provides a practical test. Multi-cloud customers will judge whether integrations, release timing and recommendations remain balanced.
Security teams need a new operating model
Agents will not simply add productivity. They change who performs work and who is accountable. Security analysts may spend less time gathering data and more time setting policy, evaluating exceptions and investigating complex attacks. Engineers will receive recommendations earlier in development.
Organisations should assign owners for agent permissions and evaluation. A security tool administrator cannot alone decide what an agent may change across production. Application, cloud, legal and risk leaders need a common governance process. Wiz can provide templates, but customers retain responsibility.
Training should include how to challenge an agent. Users need to inspect evidence, recognise uncertainty and report harmful behaviour. A polished natural-language answer can appear more reliable than it is. Interfaces should surface confidence and missing data rather than hide them.
Automation may also change staffing economics. Companies should not reduce teams based on projected efficiency before agents perform reliably through incidents and architecture changes. Human expertise is the fallback when models encounter unfamiliar conditions.
Procurement and liability cannot remain ambiguous
Enterprises buying agent capabilities will ask who is responsible when an automated remediation causes loss. Wiz can provide tools and defaults, but contracts should state the boundary among the customer, model provider, cloud platform and Wiz. Broad disclaimers would undermine the confidence needed for autonomy.
Insurance and audit teams will want evidence of controls. Exportable approval logs, evaluation results and change records can support those reviews. Service levels should cover the availability of context and policy enforcement, not guarantee that every model judgement is correct.
Procurement should also distinguish preview functions from production-ready actions. A feature labelled experimental should not acquire privileged access through a general platform approval. Administrators need a catalogue of agent tools, their risk tiers and responsible owners.
Rappaport can make governance easier by supplying standard documentation, regional data terms and deployment patterns. Reducing this administrative burden is part of the product value. It allows security teams to adopt useful automation without improvising a legal and control framework for every connection.
The winning control layer will earn permission gradually
Wiz’s security graph gives Rappaport an opportunity to become the context layer for enterprise security agents. That position could be more durable than any individual model because it depends on current customer relationships, policies and assets. It can also create deep dependence if workflows become hard to export.
The company should keep interfaces documented and allow customers to retrieve logs, policies and findings. Openness supports trust and lets enterprises combine specialised agents. Lock-in through inaccessible context would invite resistance and regulatory attention.
Assaf Rappaport can move security from alert management toward supervised action. The route should be gradual: grounded answers, explainable recommendations, bounded tools and reversible execution. If Wiz proves that automation reduces risk without creating a new privileged failure point, its graph can become essential agent infrastructure. If it pursues autonomy faster than governance, the system designed to protect the cloud could become one of its most powerful hazards.
