The new BP/36 guide from Spain’s CCN-CERT, published in June 2026, gives a name to a reality that many security teams were already noticing: the traditional model of one-off audits, annual penetration tests and patching cycles planned weeks in advance is falling short against attackers that use Artificial Intelligence to accelerate reconnaissance, exploitation, social engineering and offensive decision-making.
The central point is not that Artificial Intelligence has invented every attack from scratch. The change lies in speed, scale and automation. Well-known techniques such as phishing, exposed attack surface analysis, malicious code generation, vulnerability exploitation, credential abuse or manipulation of systems based on language models can now be executed with less effort and in less time. For companies, this shifts the focus from periodic security checks to continuous validation, resilience by design and operational response capability.
From annual pentesting to continuous validation
For years, many organisations have used the annual penetration test as a reasonable proof of security. They commissioned an assessment, received a report, fixed the priority findings and kept evidence for audit, compliance or internal improvement. That model still has value, but it is no longer enough if it is used as the only offensive security validation.
CCN-CERT refers to a “collapse of the vulnerability cycle”: identification and exploitation can happen almost at the same time. In practical terms, an exposed vulnerability in a critical service can no longer wait for the next change committee, the next monthly report or the end-of-year audit. If an attacker can automate reconnaissance, correlate public information, test vectors in parallel and prioritise targets by exploitability, defence needs to operate at a different pace.
This changes vulnerability management. Priority should not depend only on the CVSS score, but also on real exploitability, the KEV catalogue of known exploited vulnerabilities, EPSS and the criticality of the affected asset. A dashboard full of “high” vulnerabilities does not say enough unless it is cross-referenced with Internet exposure, business function, associated access, data handled and the possibility of lateral movement.
It also changes the role of the penetration test. It stops being the big annual exam and becomes part of a broader model: permanent vulnerability management, recurring offensive validation, attack simulations, continuous code review and detection controls capable of reacting in minutes or hours. The goal is not to live in a permanent state of emergency, but to reduce the distance between what the company believes it controls and what is actually exposed.
In private cloud, bare-metal or hybrid infrastructures, this approach requires more architectural discipline. The asset inventory must be alive. Networks must be properly segmented. Administrative access must be protected with phishing-resistant authentication, ephemeral credentials and least privilege. Backups must be isolated, immutable where appropriate and tested at a realistic frequency. Without these foundations, adding defensive Artificial Intelligence tools does not solve the underlying problem.
AI agents are also a new attack surface
BP/36 devotes significant attention to Artificial Intelligence agents, and this is one of its most important signals for CIOs, CTOs and CISOs. An agent that queries data, executes actions, calls APIs, modifies configurations or interacts with internal systems is not just a conversational assistant. It is an operational identity with permissions, context and impact capacity.
That nuance completely changes AI governance in the enterprise. An agent can be manipulated through prompt injection, access information that should not be part of its context, exfiltrate data through apparently legitimate responses or chain together wrong decisions if it has too much autonomy. When it is also connected to internal tools, document repositories, ticketing systems, code repositories, cloud platforms or administration consoles, it becomes part of the attack surface.
The answer is not to block all use of agents, but to govern it. Each agent should have its own identity, minimum permissions, clear limits of action, full traceability, secure credential management, input and output validation, separation of capabilities and human supervision for critical actions. The guide also mentions the need for a kill switch to stop activity if anomalous behaviour is detected.
This point is especially important for organisations that are integrating AI assistants into internal processes without involving security, architecture or compliance teams. Shadow AI may reproduce a well-known shadow IT problem, but with greater exposure capacity: sensitive data loaded into unapproved tools, automations without traceability, connectors with excessive permissions and decisions that are difficult to audit.
In a serious enterprise environment, defensive AI must be treated like any other critical system. It can help detect anomalies, prioritise events, summarise alerts, accelerate response or assist in code review, but it needs operational control. Speed without governance can create new risks. Governance without speed leaves defenders behind attackers.
Infrastructure, resilience and operations: the less visible side of security
CCN-CERT’s guide insists on going back to basics: identity, segmentation, continuous monitoring, access control, protection of critical assets, backups and disaster recovery. These are not new recommendations, but offensive Artificial Intelligence reduces the margin for error. What could previously be reviewed quarterly or annually now requires more dynamic management.
This is where infrastructure matters more than is often recognised. Security does not depend only on SOC, EDR, XDR or vulnerability scanning tools. It also depends on how the platform running critical workloads is designed: isolation between environments, private networks, route control, separation of management planes, hypervisor hardening, resilient storage, backups outside the production domain, 24/7 monitoring and tested recovery procedures.
In private cloud environments, a well-designed architecture makes it possible to combine control, performance and predictability with security measures better aligned with the company’s reality. For workloads that require isolation, low latency, dedicated performance or hardware control, bare-metal remains a solid option, especially when integrated into a broader strategy of continuity, segmentation and managed operations.
Operational sovereignty is also gaining relevance. Keeping infrastructure in Europe, with clear control over data location, providers, access, support and the regulatory framework, facilitates compliance and risk management decisions. This does not remove the need for good practices, but it reduces dependencies and allows architectures to be defined in a way that is better aligned with internal, regulatory and sector-specific requirements.
In virtualisation platforms, prior design is decisive. Migrating from VMware, on-premise environments or public clouds to Proxmox VE, KVM, bare-metal or private cloud should not be approached only as a licensing or cost decision. Network, storage, high availability, backups, recovery, segmentation, permissions, monitoring, workload compatibility and day-to-day operations must all be assessed. Proxmox VE, with KVM, LXC, HA, backups and storage options such as Ceph, can be part of a strategy aimed at reducing dependency and gaining better control over TCO, but it requires technical planning.
The same applies to incident response. BP/36 recommends adapting response times to the pace of AI-assisted threats. This means preauthorised procedures for critical scenarios, rapid isolation capability, credential revocation, malicious traffic blocking, tested restoration and clear communication between security, systems, business and providers. Resilience is not improvised during an incident; it is designed beforehand.
For companies running critical services, the message is clear: security stops being a snapshot and becomes a continuous operation. It is not enough to pass an audit. Organisations need to know which assets are exposed, which vulnerabilities really matter, which agents can act, which providers have access, which backups can be restored and how long the organisation needs to contain an attack.
Offensive AI accelerates a transformation that was already under way. Companies need less calendar-based security and more operational security: updated inventory, resilient architecture, frequent validation, agent governance, rapid response and providers capable of supporting day-to-day operations. The annual penetration test will still have a place, but as part of a broader system. Using it as the only security check will become increasingly hard to defend against a threat that no longer waits twelve months.
Frequently asked questions
Is the annual penetration test no longer useful against offensive AI?
No. It is still useful for assessing controls, detecting weaknesses and meeting audit requirements. The problem arises when it is used as the only security validation. Against automated attacks, it must be complemented with continuous vulnerability management, monitoring and recurring testing.
What is offensive AI in cybersecurity?
It is the use of Artificial Intelligence systems, including generative models and autonomous agents, to support or execute phases of an attack: reconnaissance, phishing, malicious code generation, vulnerability exploitation or operational decision-making.
Why do AI agents introduce a new risk?
Because they can have permissions, memory, access to tools and the ability to execute actions. If they are not properly governed, they can be manipulated, leak information or perform operations outside their intended function.
What should companies prioritise?
Continuous asset inventory, patching based on real exploitability, phishing-resistant authentication, segmentation, isolated and immutable backups, continuous monitoring, AI agent governance and tested response procedures.
Source: CCN-CERT, BP/36, “Guía de buenas prácticas frente al modelo de IA ofensiva”, June 2026.
