New security principles aren’t necessary with AI. We do, however, need to revisit the assumptions behind many of our long-established security decisions.
Every security program accepts risk. Controls have costs, architecture involves tradeoffs, and resources are finite. We may accept a gap because exploitation appears unlikely, compensating controls might seem sufficient, or the ideal control could appear too costly or disruptive. Those decisions may have been reasonable at the time. But the situation has changed. Do the assumptions behind these decisions still hold?
Risk acceptance has always depended on both impact and likelihood. Often, AI doesn’t change the potential impact of a weakness. It does change how quickly and cheaply we can discover that weakness, connect it to others, and use it. AI also changes the economics of defense by making some security work easier to scale across planning, engineering, validation, monitoring, and response.
The path of least resistance is getting shorter
AI will help both defenders and attackers discover novel vulnerabilities. But in many enterprise environments, the fastest path to impact will still run through weaknesses that already exist, like excessive permissions, exposed identities, misconfigurations, known vulnerabilities, and weak segmentation.
Materially changing the risk takes no novel attack chain. A human operator, or an agent operating without sufficient constraints, can use AI to execute and connect familiar stages of an attack with far less time, expertise, and manual effort. The attack chain is familiar. What is new is how fast and how cheap it has become to run.
Consider a compromised identity with broad access to shared storage. The potential blast radius already existed, but exploiting it at scale was constrained by information friction, like fragmented content, inconsistent labeling, weak indexing, and the need for human interpretation. AI-assisted analysis, or an agent running from a compromised endpoint, can rapidly enumerate, semantically classify, correlate, and infer the sensitivity and relevance of accessible information, then use those findings to guide the next step.
The same logic applies to vulnerability chaining. A finding may have been rated low or medium partly because exploitation required several difficult conditions, knowledge of an unusual configuration, or substantial manual work. An AI-assisted operator can analyze the environment, adapt code, test hypotheses, and connect weaknesses into a viable path more efficiently. Advanced models are also becoming capable of discovering novel vulnerabilities. But an attacker often will not need one when a known weakness, permissive configuration, or exposed identity offers a cheaper route.
Not every low-severity finding becomes critical. But likelihood, exploitability, and time to impact all need to be reassessed. Security leaders should pay particular attention to risks that were accepted because they were considered difficult to discover, difficult to chain, or too expensive to exploit at scale. Those are the assumptions that AI is first weakening.
Are foundational controls becoming harder to defer?
AI is not making security fundamentals obsolete. It is making gaps in their implementation harder to justify.
Zero Trust, least privilege, segmentation, managed endpoints, controlled connectivity, privileged access management, and just-in-time elevation mattered before AI. They matter more now because they limit what a human operator or agent can do after gaining a foothold.
Zero Trust cannot remain a figure of speech. Access should be based on a defined need, verified context, and the minimum scope and duration required. A trusted identity should not create a trusted path to everything around it. No program prevents every failure. The point is to keep one failure from becoming a systemic event.
The same discipline applies to AI agents. Each agent should have a defined role, a distinct and bounded identity, explicit tools, limited data access, clear action permissions, and a reliable revocation path. It should not inherit the full authority of its initiator or the service in which it runs. Its permissions should reflect the task and be time-bound where possible.
Endpoint and connectivity controls are also part of the AI security architecture. If a development agent can access source code, invoke a shell, connect externally, or authenticate internally, the organization must control its device, execution context, egress, credentials, and privileges. A responsible-use policy cannot compensate for an unmanaged endpoint or an unrestricted access path.
AI adoption arrives in an existing environment. It lands on top of legacy identities, partial segmentation, long-standing exceptions, and controls implemented unevenly across the estate. No one completes every security transformation before enabling AI. The practical task is to identify which gaps materially expand the use case's blast radius, close those first, and make the remaining assumptions explicit. Governance approval is not a substitute for technical control.
Build security in early and validate it continuously
AI also reduces the cost of security work that organizations have historically struggled to perform consistently. Security teams have advocated for secure-by-design practices for years, but coverage was the constraint. Reviewing every requirement, architecture, trust boundary, data flow, privilege model, and implementation decision required more specialist time than most organizations could provide. Security therefore often arrived after the most consequential decisions had been made.
AI-assisted workflows can extend security involvement across the engineering lifecycle. During product planning, they can help identify security requirements, sensitive data flows, abuse cases, and external dependencies. During architecture, they can challenge trust assumptions, test access models, and identify missing segmentation, logging, or failure containment. During implementation, they can help developers apply secure patterns and verify that the code reflects the intended design.
This approach puts expert guidance earlier in the process and more consistently in it and keeps ownership with the people who design, approve, and operate the system. AI-generated code and advice still require standards, review, testing, traceability, and accountability. Using AI only to scan more code after it is written preserves the old operating model. The larger opportunity is to reduce defects and blast radius before deployment.
That assurance must continue after deployment. Cloud resources change, permissions drift, integrations evolve, and agents acquire new tools or responsibilities. Point-in-time reviews are weak evidence that a changing environment remains secure. Continuous assurance does not require testing every control at all times, only revalidating the controls most likely to drift when infrastructure, permissions, integrations, agent capabilities, or relevant threat information changes. What matters is confirming that critical controls still produce the intended outcome. That means checking which paths are reachable, what permissions allow, whether segmentation holds, whether telemetry is complete, and whether compensating controls work in practice.
AI-assisted adversarial testing can expand that coverage. Authorized agents can explore attack paths, combine weaknesses, and retest controls after changes. The aim is more frequent, controlled adversarial validation across a larger portion of the environment. It does not replace expert testers. Scope, safe techniques, audit trails, enforceable stop conditions, and human judgment remain essential.
Continuous assurance must also extend beyond the systems an organization operates directly. AI adoption increasingly depends on third-party services, connectors, models, and development tools, so review must examine the integration itself, including its access, permitted actions, telemetry, revocation path, and compensating controls. Threat intelligence should feed the same process by triggering rapid exposure assessment and bounded defensive action, even before formal vulnerability classification or a vendor patch is available.
Monitoring and incident response must operate at the new speed
Secure design, least privilege, and continuous assurance reduce attack paths, but they do not remove the need for monitoring and incident response. AI can compress the time between initial access and business impact. A human operator can use it to accelerate reconnaissance and decision-making, while a compromised or poorly constrained agent may already possess legitimate access to tools and information.
An attacker can therefore work with valid credentials, through approved interfaces, and at a speed that produces large volumes of individually plausible actions. Detection needs enough identity, cloud, endpoint, application, and data context to distinguish expected automation from unauthorized or unsafe behavior.
The transformation shortens the path from signal to understanding and from understanding to containment. Putting AI in front of an existing alert queue does not do that. AI-assisted investigation can correlate evidence, reconstruct timelines, test hypotheses, identify affected assets, and recommend response options. Bounded automation can collect evidence, revoke a session, or isolate a workload through predefined playbooks.
High-impact actions still require appropriate control. Some can be preauthorized within narrow conditions; others should require human approval. In both cases, authority, provenance, and auditability must be clear. Automating an unclear or overly privileged process does not make it safer. It speeds up errors.
Prevention, monitoring, and response are parts of the same resilience model. Reduce the available attack paths, watch the paths that remain, and contain activity before access becomes material impact.
The leadership task is to identify where earlier risk decisions depended on assumptions that no longer hold and to update the architecture, controls, and operating model accordingly.