Reports about the recent PHP security vulnerabilities have given business leaders another reason to ask whether their systems are safe. PHP is software used to run websites and business applications. Your company may depend on it through a purchased application or hosting service, even if no one on the management team has heard of it. The October disclosures concerned defects that could allow outsiders to run code on affected systems. The developers who maintain PHP released corrections, and the U.S. Cybersecurity and Infrastructure Security Agency subsequently added two of the vulnerabilities to its Known Exploited Vulnerabilities catalog.[1][2]
The immediate response is to identify affected systems and apply the appropriate corrections. Management also needs to understand the broader exposure. The business depends on software it may not have overtly selected, maintained, or reviewed (whether recently or at all). At the same time, in the interest of doing their day-to-day work, employees and consultants are connecting new AI tools to company information and giving them authority to act. Those connections can expose internal systems to outsiders in ways that an ordinary software purchase review may never address.
The people building these solutions may be doing exactly what the company encouraged: improving service, reducing repetitive work, and producing better results. A useful demonstration can nevertheless conceal access to unrelated files, permission to send information outside the company, or reliance on someone else’s unreviewed code. Management needs to know what has been authorized, who controls it, and what happens when something goes wrong.
The fixes to limit the effects of malicious exploitation of vulnerabilities in your systems certainly lie in your engineering group, but the legal ramifications need to be managed in parallel. In order to do that, awareness of the specifics becomes increasingly strategically important.
This overview addresses those decisions. The longer article, Storming the Castle, provides the detailed technical examples, legal authorities, and supporting analysis: [URL].
Familiar protections and unfamiliar exposure
For decades, businesses have defined “Malicious Code” in agreements, representations, warranties, and operating procedures. Viruses, worms, and Trojan horses are familiar examples. Companies obtain supplier assurances, make commitments to customers, and expect their security teams to prevent harmful software from entering their systems.
The present risks require a broader review of how the emerging generation of AI-based tools creates and leverages vulnerabilities in your business architecture. An unknown defect in legitimate software may permit an attack even though the supplier introduced no malicious code. A trusted update may be compromised before installation. An instruction hidden in a communication or user content that makes its way onto your system may redirect an AI system without installing a conventional virus. A downloaded automation script may unintentionally expose information simply because it has more access than its assigned task requires.
These events can produce similar losses, but they call for different safeguards and contractual provisions. Changing the definition of malicious code will not establish who maintains a vulnerable component, who approves a new connection, or who pays when an agent sends confidential information to the wrong recipient. The company needs to address those responsibilities expressly.
The first organizational difficulty is that several people may approve different parts of the arrangement. A business unit selects the application, IT connects it, procurement negotiates the subscription, legal reviews confidentiality, and security evaluates the supplier. Someone still needs responsibility for the combined system and its actual capabilities.
“Patch-as-You-Go” May be Harder than you think
The PHP disclosures illustrate why management should ask for more than confirmation that an update was downloaded. Subsequent notices addressed particular settings and corrected Windows packages whose underlying PHP version number remained unchanged. Verification depended on the configuration and the package actually running.[1]
The technical team should determine which correction applies. The business needs to establish who is responsible for obtaining and deploying it, including when a hosting provider or software vendor controls the environment. A maintenance ticket is useful only if someone can confirm that the affected service has been corrected or identify the exposure that remains.
There are operating decisions as well. A critical update may require an interruption, testing, or coordination across several providers. If a correction cannot be deployed promptly, management may need to restrict a feature or suspend a service. Customer commitments, notice obligations, alternative arrangements, and the authority to accept temporary risk should be considered before the company is making those choices under incident pressure.
AI may increase both the ability to discover old defects and the ability to correct them. Mozilla has described AI-assisted work identifying longstanding Firefox bugs, including defects that had remained for fifteen and twenty years, and helping fix them.[3] That supports planning for further discoveries in established software. It does not establish that AI caused the PHP defects or that every older system is compromised.
Assistants, skills and MCP’s – Useful tools with more access than expected
An AI assistant that prepares a draft presents different risks from a system that can retrieve files, update records, and send the finished result. An “agent” can perform a sequence of actions, using the result of one step to decide what to do next. The company determines how much of that work can proceed without further approval.
A consultant might build an agent that reads incoming customer requests, searches the company’s files, checks an order, and prepares a response. To make it useful quickly, the consultant might connect it through an employee’s existing account. That account may also reach confidential pricing, other customers’ records, and administrative functions. A demonstration using an ordinary request may reveal none of that additional access.
A solution can produce accurate answers and save substantial time while retaining unnecessary permissions. Testing whether it performs the requested work will not necessarily show what else it can do. The review should include unintended actions and access, including functions inherited from another tool. Employees should be able to explain the business benefit; qualified reviewers should separately establish the limits within which the solution can operate.
Publicly available outside-party markdown files, “skills” and agent scripts deserve the same attention. A skill may contain reusable instructions, executable code, or references to other tools. A script can automate actions on a computer or across connected services. Their names tell management little about their capabilities. A small download can have substantial consequences if it can read company files, obtain account credentials, or transmit information externally.
This risk extends to tools used by developers. In its May 2026 account of the Nx Console compromise, the publisher described a malicious software package that enabled theft of a contributor’s credential and subsequent distribution of a compromised editor extension. The extension targeted credentials on machines where it ran.[4] The company’s development environment therefore belongs in the review alongside its customer-facing applications.
Good intentions do not determine the permissions a tool receives. Nor does a familiar publisher establish that every update, connection, and later change is appropriate. Employees and consultants need a workable approval process that identifies the proposed use, the information involved, the actions permitted, and the person responsible after delivery.
Instructions hidden in ordinary content and communications
Prompt injection occurs when hostile content is treated as an instruction to an AI system. An attacker may put directions in an email, a web page, a supplier proposal, or another document the system is expected to read. If the system follows those directions, it may depart from the company’s task or restrictions.[5]
Consider the customer-service agent. An incoming message asks about an order but also instructs the agent to retrieve the company’s confidential pricing file and send it to a new address. The request to read the message is legitimate. The sender’s attempt to control what the agent does next is not. Whether the attempt succeeds depends on the system and the authority available to it.
The distinction matters because employees need not click a suspicious attachment for this class of problem to arise. Microsoft’s June 2025 Copilot disclosure and the related EchoLeak research described a vulnerability involving a crafted email that could cause disclosure of internal information without the recipient clicking a malicious link. The research demonstrated a vulnerability; it did not establish that a particular customer suffered a breach.[6][7]
Disclosure is only one possible result. A résumé could contain instructions to rank its author first. A proposed contract could instruct an automated reviewer to overlook an unfavorable clause. Those are illustrative scenarios. They show why the review must include the reliability of business decisions, even when no information leaves the company.
Filters, instructions to the model, and human review can help. Access restrictions also need to operate in the connected systems. An agent assigned to summarize a mailbox does not need permission to delete messages or send attachments to arbitrary recipients. Where prior work is retained and reused, the company should also test whether hostile material can affect a later task.
MCP’s – Gateways between systems
The Model Context Protocol, or MCP, is a standard way for AI applications to connect to tools and information sources. An MCP server is software that provides a capability, such as retrieving documents, changing customer records, or sending messages. It may run on an employee’s computer or at an outside provider. The AI application using those connections is called the host.[8]
MCP can make useful connections easier to build. The company still has to decide which connections are appropriate and what each may do. Access to one customer’s documents differs from access to a whole shared drive. Permission to prepare a message differs from permission to send it. Using a common protocol does not make those business decisions.
In a 2025 demonstration, Invariant researchers placed a malicious instruction in a public GitHub issue. An agent with access through GitHub’s MCP integration retrieved private repository information and disclosed it through a public proposed code change. The demonstration depended on the available permissions and execution settings; individual approvals were available, while an “Always Allow” setting removed that review.[9]
The example does not establish that every MCP connection is unsafe. It shows why the company must assess what happens when outside content, internal information, and authority to act are combined. A legitimate connection can be misused by a manipulated agent.
Ownership and management matters after launch. A server operator may add capabilities, a supplier may change its service, or an employee may connect another repository to improve the results. Those changes can alter the approved arrangement. The company needs notice of material changes and a way to reassess them before sensitive access expands. Responsibility should remain assigned after the consultant finishes the project or the original developer changes roles.
MCP policy should identify who may approve servers and their operators, grant access, accept material changes, and revoke connections. It should cover the capabilities supplied through them. Other software can create comparable access through browsers or direct system connections, so a policy limited to the MCP label would leave similar arrangements unexamined.
The “Lethal Trifecta” – a combination that warrants immediate review
Software developer Simon Willison describes three capabilities together as the “lethal trifecta”: access to private data, exposure to untrusted content, and the ability to communicate externally.[10] Management can use those categories to identify deployments requiring closer review. A negative answer to one does not establish that a system is safe in every other respect.
Three capabilities to review together
Adapted from Simon Willison’s “lethal trifecta.” This identifies a disclosure risk; it is not a complete safety assessment.[10]
External communication includes more than sending email. Uploads, public comments, and requests to outside services can transmit information. Authority to act also includes changing payment details, updating customer records, publishing statements, or accepting terms. The company should identify these actions expressly, including those available through an employee’s inherited permissions.
For the customer-service agent, the company might permit access to the relevant order and preparation of a draft, while requiring approval of the actual recipient, attachments, and message before transmission. Approval should apply to that specific action. A later change to the destination or content should require renewed review.
The reviewer needs enough time and information to make the decision, together with authority to stop the process. Clicking approval because the agent says everything is acceptable supplies little assurance. Security staff should be able to demonstrate that the restrictions remain effective when the agent receives a hostile instruction. OWASP’s guidance on excessive agency likewise recommends limiting functionality, permissions, and autonomy, with independent authorization for consequential actions.[11]
Durable legal obligations
Calling software an agent does not create a separate legal person responsible for its conduct. Existing rules concerning contracts, security, confidentiality, and representations remain relevant. Ohio’s electronic-transactions statute, for example, permits contract formation through interacting electronic agents even when no individual reviewed their actions or the resulting terms, while preserving applicable substantive law.[12] The absence of a person clicking “accept” does not by itself answer whether a commitment was made.
A supplier’s terms may assign configuration, connected tools, and output review to the customer. Meanwhile, the company may have promised its own customers restricted data use or human approval of important decisions. Counsel needs to compare those obligations against the same potential failure and identify any gap in recovery.
Insurance requires the same attention. Cyber coverage, technology errors and omissions coverage, and any AI exclusions should be reviewed against the actual deployment. A policy may distinguish between different causes, services, and injuries. A supplier indemnity or insurance certificate does not establish that the company will recover its own response costs or satisfy every customer claim.
The response may also require business judgment before the extent of the incident is known. Someone must decide whether to interrupt a customer service, withdraw an automated communication, or temporarily require manual approval. Counsel should help identify applicable notice and preservation obligations while management considers continuity. Those decisions are easier when the company already knows the system’s owner, its providers, and the records available to reconstruct its actions.
The company also needs a proportionate record of its decisions and tested safeguards. That record should identify access, material changes, approvals, and unresolved findings. Retaining everything indefinitely can create another collection of confidential information. Counsel and engineering should agree on useful records, access controls, retention periods, and preservation when required.
So what should we do in addition to employing great engineers? Five business and legal priorities
Management can begin with the systems that have sensitive information, outside access, or authority to change important records. The objective is to identify what exists, decide what is permitted, and obtain evidence that the limits work. The following steps are management recommendations; specific legal requirements depend on the company’s activities, contracts, and applicable law.
1. Context-Aware AI Policy
As we’ve said before, it’s difficult to find a one-size-fits-all AI policy. A well-crafted policy will reflect the specifics of both business operations and known technological and legal specifics. Assign a business owner to each consequential use, with named technical and legal reviewers. Approval should identify the purpose, permitted information, connected systems, and authorized actions. It should also identify who can approve a change, accept an exception, or suspend the system.
Include employees and consultants who build automations, install skills, or connect outside services. Give them an approval process they can use before development becomes an operating dependency. Require disclosure of external providers, downloaded components, and credentials used. An approved AI subscription should not automatically authorize every tool later attached to it.
The policy should establish escalation when a critical vulnerability is disclosed or a provider becomes unavailable. Identify who decides whether work continues and what temporary alternatives are available. Management should receive a concise record of approved uses and unresolved exceptions, with an owner and review date for each. A general instruction to “use AI responsibly” leaves those decisions unanswered.
2. Exposure Audits
Ask security and engineering to test representative workflows, including the conditions under which they might fail. Review a hostile incoming document, a compromised component, an unexpected destination, and an attempted action outside the approved task. Confirm whether the restrictions actually prevent the action or merely ask the model to avoid it.
The inventory should include developer tools, locally installed connectors, outside-party skills, and consultant-built scripts. For PHP and other dependencies, obtain evidence of the corrected software running in the relevant service. Where a provider controls it, identify the evidence that provider will supply and who evaluates it.
Test withdrawal of access as well as initial approval. The company should know whether it can stop work already underway and remove credentials when an employee, consultant, or service relationship ends. Findings need accountable owners, correction dates based on risk, and verification. An exception should be an express business decision supported by the facts, not an unresolved ticket that disappears from attention.
3. Intelligent terms and conditions your company can actually live with
In addition to measures taken at a systems level, a critical parallel step is to assess the specific terms and conditions of your internal and external legal agreements, testing them against the realities of your enterprise. Review supplier duties, customer commitments, content licenses, and insurance against the same scenarios. Test malicious-code language against compromised software and hostile instructions, while separately addressing maintenance, newly discovered vulnerabilities, and changes to connected capabilities.
The agreement should identify who assesses exposure, installs corrections, verifies completion, and gives notice when the service cannot be made safe promptly. Seek cooperation in investigation, access to relevant records, preservation arrangements, and workable suspension or exit rights. Evaluate remedies, liability caps, and exclusions against the likely business consequences.
Consultant engagements should require delivery of the information needed to operate and maintain the solution: components, connections, authorized access, and responsibility for updates. Review whether third-party subscriptions permit the proposed automated use or onward transfer of content. If supplier remedies and insurance leave a material gap, management should decide whether to restrict the use, obtain additional protection, or accept the identified exposure.
4. Data and document control
Have information owners identify what each tool may access, why it needs that information, and where the information may go. Review existing permissions before connecting a mailbox, shared drive, or document repository. An employee’s broad access should not become an agent’s default access merely because it is convenient.
Over time, you can expect commercially available tools to act much like antivirus software has for decades, extending the logic to the full range of emerging vulnerabilities. Until that happens, treat externally supplied documents as material for analysis, with no authority to change the company’s instructions. Apply that distinction when content is copied into internal systems or retained for later work. Identify approved recipients, external services, and any restrictions on storage, reuse, or training.
Whether or not better tools help thwart vulnerabilities, the resulting record should connect data permissions to an actual business purpose. Include deletion and retention arrangements, the records available from providers, and the ability to preserve relevant information when required. For sensitive evaluations, such as contract or supplier review, establish how a qualified person can identify manipulation before the company acts on the result.
5. Architecture review and code containment
Ask engineering to demonstrate what remains protected if a component is compromised or an agent follows an attacker’s instruction. The review should address isolation of executable code, access limited to the task, permitted outside destinations, and authority to alter business records.
For higher-risk work, separate preparing an action from approving and executing it. Require meaningful approval of the recipient, information, amount, or record involved. Confirm that restrictions are enforced by the software and connected services, independently of whether the model follows its instructions.
Containment also requires a practical response. Identify who can disable a connection, revoke credentials, isolate affected work, and maintain essential operations while the problem is investigated. Management should approve the resulting operating limits and the circumstances requiring suspension. It should expect evidence that the restrictions work, with responsibility assigned for reassessment as the system and its uses change.
You got this.
These risks call for the same disciplined management the company applies to any significant, emerging enterprise risk. Leadership sets objectives and risk tolerance, assigns accountability, and relies on qualified specialists in engineering, security, legal, and operations to design safeguards and risk mitigation strategies. Management then confirms that those safeguards are likely to work as intended and revisits its decisions as the systems and threats change. Unfortunately, there is no silver bullet. No single product or policy will resolve these issues. The good news is that, because the threats affect so many organizations, businesses, researchers, and technology providers are openly sharing their findings and concerns, and management can draw on that collective experience. The task for leadership is to apply what that community is learning to the company’s own operations, contracts, and priorities.
KJK’s AI Strategy, Risk Management & Compliance practice group would welcome the opportunity to review, audit, and counsel on any of the solutions outlined in this article, and/or just discuss your concerns and identify potential priorities for review.
Author Note
This article summarizes a longer analysis. The full white paper covers the PHP and Nx incidents in technical detail, the Ohio and California authorities on automated conduct, and a framework for comparing supplier terms, customer commitments, and insurance against a single incident. It also includes the complete source list.
Download the full white paper: Storming the Castle (PDF)
Selected sources
[1] PHP development team, security and release notices (Oct. 21, 23, and 26, 2026), News Archive 2026. Source
[2] Cybersecurity & Infrastructure Security Agency, CISA Adds Two Known Exploited Vulnerabilities to Catalog (Oct. 26, 2026), CVE-2026-109618 and CVE-2026-109619. Source
[3] Brian Grinstead, Christian Holler & Frederik Braun, Behind the Scenes Hardening Firefox with Claude Mythos Preview, Mozilla Hacks (May 7, 2026). Source
[4] Nx, Postmortem: Nx Console v18.95.0 Supply-Chain Compromise (May 21, 2026), incident sequence and credential collection. Source
[5] OWASP Gen AI Security Project, LLM01:2025 Prompt Injection, indirect injections, consequences, and mitigations. Source
[6] Microsoft, M365 Copilot Information Disclosure Vulnerability, CVE-2025-32711 (June 2025), assigning-authority CVE record. Source
[7] Pavan Reddy & Aditya Sanjay Gujral, EchoLeak, arXiv:2509.10540v1, §§ 3–5 (Sept. 6, 2025). Research preprint analyzing the disclosed vulnerability. Source
[8] Model Context Protocol, Architecture (June 18, 2025 specification), hosts, servers, and security responsibilities. Source
[9] Marco Milanta & Luca Beurer-Kellner, GitHub MCP Exploited: Accessing Private Repositories via MCP, Invariant Labs (May 26, 2025). Research demonstration. Source
[10] Simon Willison, The Lethal Trifecta for AI Agents: Private Data, Untrusted Content, and External Communication (June 16, 2025). Source
[11] OWASP Gen AI Security Project, LLM06:2025 Excessive Agency, functionality, permissions, autonomy, and independent authorization. Source
[12] Ohio Rev. Code Ann. § 1306.13(A), (C) (automated transactions and preservation of substantive law). Source