Why Faster Attacks Demand Architectural Containment
On September 14, 2026, the Spanish Data Protection Agency (AEPD) disclosed what it described as the first notified personal-data breach caused by an attack executed through an artificial intelligence agent.
According to the agency’s preliminary account, the agent searched for vulnerabilities, logged in successfully, and then autonomously searched the application for further weaknesses. Once it found them, it modified personal data and accessed billing records. The analysis is ongoing, and the agency notes that the use of a particular AI model does not imply that the model or its provider was compromised. An attacker appears to have used an AI agent to carry out familiar offensive-security tasks with an unusually high degree of autonomy.
That distinction is important. AI did not invent a new vulnerability or a new category of cyberattack. It accelerated an attack process security teams already understand—one that, in this case, passed through a successful login before it ever reached the data.
The lesson is not merely that organizations need to detect attacks faster. It is that every Internet-connected server must be designed with the expectation that it will eventually be compromised—or induced to perform an unauthorized action. AI makes that expectation more urgent, but it did not create it.
Assume the Server Will Be Compromised
Traditional security strategies focus on keeping attackers outside the system: firewalls, endpoint protection, multifactor authentication, vulnerability scanners, application gateways, monitoring platforms, and security operations teams. Those controls are necessary. They are not sufficient.
Any server exposed to users, applications, vendors, administrators, APIs, or the Internet lives in a continuously changing attack environment. New vulnerabilities are discovered. Credentials are stolen. Software dependencies are compromised. Access rules are misconfigured. Trusted integrations are abused. Given enough time, organizations should expect prevention to fail somewhere.
That does not mean every server will be compromised immediately. It means secure architecture cannot depend on the assumption that the server will remain trustworthy forever. The design question is not only how to prevent compromise, but what happens when compromise occurs. That is the practical meaning of “assume breach.”
For sensitive and regulated data, the server should be treated as a component that may eventually become hostile—controlled by an attacker or manipulated into returning information the requester was never authorized to receive. If that server can reach an aggregated plaintext dataset, or holds the authority to decrypt an aggregated encrypted one, a single failure can become a wholesale breach.
The Attack Chain Is Moving Toward Machine Speed
A conventional intrusion often requires a human operator to move through a series of steps:
- Identify a potential target.
- Enumerate its externally accessible systems.
- Locate a vulnerability or exposed credential.
- Establish initial access.
- Explore the application and infrastructure.
- Identify valuable data.
- Extract, alter, encrypt, or destroy that data.
Each step historically introduced delay. An attacker had to interpret results, select another tool, revise a command, or decide where to move next. Those delays gave defenders opportunities to patch a vulnerability, notice an abnormal request, disable a session, isolate a workload, or interrupt data exfiltration.
AI agents can compress those steps into a much shorter cycle. They can analyze responses, generate or modify commands, choose follow-on actions, and keep operating without waiting for a person to evaluate every result.
The shift is visible beyond a single incident. Verizon’s 2026 Data Breach Investigations Report found that, for the first time, vulnerability exploitation had become the most common initial-access vector in its dataset, accounting for 31% of breaches. Verizon also warned that attackers’ use of AI is shrinking the time between public disclosure of a vulnerability and active exploitation from months to hours. CISA’s Binding Operational Directive 26-04 likewise warns that attackers’ use of AI “may further narrow the time defenders have to react between patch release and possible exploitation.”
The defensive window is not disappearing, but it is getting smaller. In some cases, exploitation may begin before an organization can test and deploy a patch. That makes it increasingly dangerous to build a security strategy around the expectation that defenders will always respond before an attacker reaches the data.
None of this requires an intelligent machine inventing unprecedented attacks. The risk is an automated system applying known techniques faster, more persistently, and at greater scale. An attacker who previously could examine dozens of potential targets may be able to examine thousands. A vulnerability that once required sustained human attention may become accessible to less sophisticated actors. An intrusion that previously unfolded over days may advance from initial access to data discovery before a manual security process can respond.
Organizations should improve vulnerability management, identity security, monitoring, and automated response. But faster defenses address only part of the problem. The more fundamental question is what an attacker can obtain after one of those controls fails.
An Attacker Does Not Need Full Control of the Server
A major data breach does not always require an attacker to seize administrative control of an operating system or cloud account. Sometimes the application itself can be manipulated into retrieving information for an unauthorized user.
SQL injection is the classic example. When an application incorporates unsafe user input into a database query, an attacker may be able to alter the intended query—reading tables, bypassing authentication controls, modifying records, extracting credentials, or accessing information belonging to other customers. From the database’s perspective, the query arrives through a legitimate application account. The database does not know that an unauthorized person caused the application to issue it.
Other attacks can produce similar results:
- Broken access control may allow one user to request another user’s records.
- Insecure direct object references may expose data when an attacker changes an identifier in a URL or API request.
- API authorization failures may allow authenticated users to access functions or records outside their assigned privileges.
- Server-side request forgery may cause a trusted server to access internal systems on an attacker’s behalf.
- Command injection or remote-code execution may allow an attacker to operate with the application’s privileges.
- Stolen sessions or credentials may make an unauthorized user appear legitimate.
- Compromised integrations may use valid tokens to retrieve large quantities of customer data.
- Misconfigured cloud services may expose records without requiring the attacker to defeat the application.
- Insider misuse may exploit access that was technically authorized but used for an unauthorized purpose.
These attacks differ technically, but they share a structural weakness: the server or application has aggregate access to more data than the requester should receive. When the application can retrieve every customer’s information, a flaw in the application becomes a flaw in the security boundary protecting every customer.
Centralized SaaS Architecture Rewards Successful Attackers
Most software-as-a-service platforms are built around centralized authority. The application server needs access to a shared database. That database holds information belonging to many customers or users, and a small number of service accounts may have permission to query enormous portions of it.
The records may be encrypted, with keys held in a separate key-management system, hardware security module, or secrets manager. Those are valuable controls against lost media and accidental disclosure. But the system must still be able to decrypt the protected records during normal operation.
That creates a fundamental problem: encrypting aggregated data does not contain a server compromise when the same server-side trust domain can access both the ciphertext and the means to decrypt it. If the application or database can request decryption during normal operation, an attacker who compromises that workload may be able to use the same path—stealing the credentials that authorize calls to a key-management service, invoking decryption without ever extracting a key, querying records through legitimate database functions, or simply capturing plaintext after the database returns it to the application.
The attacker does not need to break the encryption. The compromised system may decrypt the data for them. Restricting server-side access to keys is not the same as separating decryption authority from the server.
AI makes this concentration of authority more dangerous. Centralized infrastructure gives an automated attacker an efficient collection point. Once the agent finds one exploitable path, it does not need to compromise every customer separately. It can target the system that already has access to all of them.
Detection and Containment Solve Different Problems
Detection asks:
Can we recognize malicious activity quickly enough to stop it?
Containment asks:
If we do not stop it in time, how much can the attacker obtain?
Both are necessary, but only containment can limit the damage after detection fails.
No combination of controls will detect every attack before data is accessed. Some attacks exploit previously unknown vulnerabilities. Others begin with a successful login, as the AEPD case did. A SQL-injection attack may execute through the application’s normal database connection. A broken authorization check may produce an ordinary API response. By the time a security team understands what happened, the data may already be gone.
Architectural containment begins with that expectation. Under an assume-compromise model, an organization should ask:
- Can one application credential retrieve data belonging to every customer?
- Can one malformed query expose an aggregated dataset?
- Can the server obtain or invoke the keys needed to decrypt all stored information?
- Can changing an object identifier return another user’s records?
- Can a privileged account perform a bulk export?
- Where does plaintext appear in databases, application memory, logs, caches, and backups?
- What remains protected if an attacker copies the complete server-side environment?
- Does one compromised component expose one user, one group, one tenant, or the entire platform?
These questions measure blast radius rather than merely the probability of initial compromise. As attacks accelerate, blast radius becomes one of the most important security properties a system can control.
A Different Role for the Server
BrunnrDB is being developed around a different division of responsibility. In a conventional SaaS architecture, the central application and database are trusted to process plaintext for many users. BrunnrDB is designed to remove that authority from the central hosting environment.
The server stores and transports encrypted data packages, while authorized client or edge environments perform protected processing using keys that are not stored on—or available to—the server. The objective is not merely to place stronger restrictions around server-held keys. It is to prevent the central server, database, and key-management path from collectively possessing the capability to recover every user’s protected data.
A system in which the server stores ciphertext but can retrieve the keys or invoke a decryption service is an encrypted server.
A system in which the server stores ciphertext but cannot obtain the keys or invoke a service that decrypts the protected content is a ciphertext-only server.
Only the second model materially changes what a compromised server can surrender. A sufficiently compromised server must be assumed capable of exercising every permission assigned to it. If it can request a key, call a decryption service, or issue a query that returns plaintext, the attacker inherits those same capabilities. So the meaningful security boundary cannot be:
The server has access to the keys, but only under restricted conditions.
It must be:
The server does not possess the keys and has no server-side path for using them to recover the protected content.
BrunnrDB combines several architectural elements toward that boundary:
- Ciphertext-only server storage: Central infrastructure is intended to store encrypted packages without possessing the user keys required to recover their protected contents.
- Separation of decryption authority: The server should not be able to obtain the keys, invoke a server-side decryption service, or use an application credential to recover the aggregated plaintext dataset.
- Client-side or edge processing: Decryption, queries, and application logic involving protected data move toward an authorized client or edge execution environment.
- Shard-by-access segmentation: Data is divided according to who is authorized to use it, reducing dependence on one broadly accessible multi-tenant dataset.
- Package-level cryptographic protection: Individual data packages use separate cryptographic protection rather than relying exclusively on a single database-level encryption boundary.
- Cryptographic provenance and integrity: Linked and signed packages are designed to support verification of origin, integrity, and state history.
This changes the consequences of server compromise. If an attacker gains administrative access to the server, copies the database, steals server-side credentials, compromises the application, or causes the database to execute an unintended query, the attacker may be able to exfiltrate encrypted packages and limited public metadata. The central environment, however, should not contain the user keys—or an authorized path to invoke them—needed to convert those packages into a wholesale plaintext dataset. Compromising one user, device, or key should not create a path to every other user’s information.
SQL injection against a conventional encrypted database may still expose readable information because the database decrypts the requested records as part of normal query processing. Against a ciphertext-only storage environment, an unauthorized query may expose encrypted packages, identifiers, or limited public metadata, but the server cannot simply ask its database or key-management service to decrypt the contents.
This does not make SQL injection or server compromise acceptable. Both must still be prevented, detected, and corrected. The difference is that the failure of those controls does not automatically include the failure of the cryptographic boundary. That is defense in depth at the data layer.
What Architectural Containment Does Not Mean
No responsible security architecture should be described as invulnerable, and AI agents do not change that principle. Moving protected processing away from the central server does not eliminate the need for secure development, injection prevention, strong authorization, rapid remediation, multifactor authentication, credential and endpoint protection, monitoring and incident response, sound key management and recovery, or independent security testing.
If an attacker compromises an authorized endpoint while that endpoint is using data, information available within that authorized context may still be exposed. A malicious recipient may misuse information that was legitimately shared. Public metadata and traffic patterns may reveal operational information even when the protected payload remains encrypted.
The purpose of containment is not to claim that nothing can ever be compromised. It is to prevent one compromised server, vulnerable query, stolen service credential, or broken authorization check from automatically becoming a compromise of everyone’s data.
Security Architecture Must Account for Response Time
Many security programs implicitly assume defenders will have time to react—to review an alert, revoke credentials, deploy a patch, and stop data extraction. AI-enabled attacks put pressure on that assumption. When reconnaissance, exploitation, discovery, and collection can occur in one automated sequence, the architecture itself must limit what that sequence can reach.
This leads to a practical design principle:
The faster an attacker can move, the less a system should depend on human intervention to contain the damage.
Architectural controls operate before an analyst reads an alert. A server that does not possess user decryption keys cannot surrender those keys simply because the response was delayed. Cryptographically segmented data also cannot be aggregated through a single database credential in the same manner as a conventional shared plaintext dataset. The server should not have to recognize an AI attacker to avoid revealing information it was never capable of decrypting.
The Question Every Organization Should Ask
AI agents will make many existing cybersecurity problems faster, cheaper, and easier to scale. Defensive AI and machine-speed incident response will be part of the answer. But an automation race should not obscure the architectural issue underneath it.
The most useful question is not:
Can we stop every AI-enabled attack before it gets in?
We already know the answer. No organization can prevent every successful attack indefinitely. The more durable question is:
When the server is compromised—or manipulated into serving an unauthorized request—what information can it actually give the attacker?
If the answer is an aggregated plaintext dataset covering thousands or millions of people—or an encrypted one the compromised server can still decrypt—the architecture remains dependent on perfect prevention and immediate response.
BrunnrDB is being built around a different objective: infrastructure that can continue storing, transporting, and coordinating sensitive data without possessing the keys or centralized decryption authority that turn one successful exploit into a wholesale breach.
The server will be attacked. Eventually, some preventive control will fail. AI agents only make that reality arrive faster. Containment cannot begin after the alert. It must begin with the way the data is stored, divided, accessed, encrypted, and processed.
Weighing what your own servers could surrender? We would be glad to compare notes on your architecture. Get in touch with Mimir Security →
Sources
- Spanish Data Protection Agency (AEPD). “Primera notificación de una brecha de datos personales causada por un ataque ejecutado mediante un agente de IA” (First notification of a personal-data breach caused by an attack executed through an AI agent). September 14, 2026. https://www.aepd.es/prensa-y-comunicacion/blog/primera-notiviacion-brecha-datos-personales-causada-por-ataque-ejecutado-mediante-agente-ia
- Verizon. “2026 Data Breach Investigations Report.” https://www.verizon.com/business/resources/reports/dbir/
- CISA. “BOD 26-04: Prioritizing Security Updates Based on Risk.” June 10, 2026. https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
