AI just changed the threat model.
Recent public discussions around AI safety benchmarks and sandbox escapes point to a broader security question that enterprises cannot ignore.
The important question is not only whether we are impressed or concerned by what autonomous AI systems can do today.
The important question is this:
What happens when autonomous AI becomes a normal attacker inside enterprise networks?
Traditional security assumes human limits
Traditional security often assumes that an attacker is human.
A human attacker gets tired.
A human attacker makes mistakes.
A human attacker has limited time, attention and patience.
A human attacker may miss a path, stop after a failed attempt, or need time to understand an unfamiliar environment.
An autonomous AI agent changes those assumptions.
It may:
- continuously search for new attack paths,
- chain vulnerabilities,
- adapt in real time,
- operate 24/7,
- learn from every failed attempt,
- and repeat discovery, exploitation and lateral-movement logic at machine speed.
That changes the defensive model.
Existing tools remain important, but insufficient
Firewalls still matter.
Antivirus still matters.
Vulnerability scanners still matter.
Logging, SIEM, endpoint protection and patch management still matter.
But they are no longer sufficient on their own.
In a world of autonomous AI attackers, the key question becomes different.
Not only:
Did we detect an attack?
But also:
Can we continuously prove that this system is still trustworthy?
That is a much harder question.
Trust can no longer be assumed
For years, many environments have operated on implicit trust.
A server is trusted because it is inside the network.
A configuration is trusted because it was approved once.
A package is trusted because it was installed from a known source.
A control is trusted because an audit document says it exists.
That model is too weak for the next phase of cybersecurity.
Trust must be continuously measured, verified and proven.
This is where Zero Trust becomes more than a slogan.
Zero Trust is not only about identity or network segmentation. It is also about evidence. It is about knowing whether the system you are relying on is still the system you intended to run.
Why I am building FILIP.OS
This is one of the reasons why I am building FILIP.OS.
Not another security dashboard.
A platform focused on continuous trust evidence.
The direction is clear:
- continuous integrity verification,
- Zero Trust principles,
- immutable audit evidence,
- compliance as code,
- automated evidence collection,
- AI-ready governance.
The goal is not to create another screen full of alerts.
The goal is to help organizations prove whether their infrastructure is still in the expected state.
That difference matters.
A dashboard can show that something happened.
Integrity evidence can help prove what changed, when it changed and whether the current state still matches what was approved.
Compliance must become executable
NIS2, CRA, internal audits and security policies all point in the same direction.
Organizations need more than policy documents.
They need evidence that controls are working.
They need evidence that systems are maintained.
They need evidence that changes are detected.
They need evidence that infrastructure integrity is not merely assumed.
This is why compliance as code matters.
If compliance remains a folder full of PDFs, it will not survive the speed of modern infrastructure or the pressure of AI-assisted attacks.
Controls must become measurable.
Evidence must become machine-readable.
Audit trails must become harder to manipulate after the fact.
Where FILIP.OS is heading
Future releases of FILIP.OS will expand this vision with capabilities such as:
- continuous integrity monitoring,
- AI-assisted compliance planning,
- CRA and NIS2 assessment as code,
- immutable cryptographic audit evidence,
- centralized governance across Linux infrastructure,
- machine-readable security evidence for automated audits.
This is not only about detecting malware.
It is about reducing uncertainty.
It is about creating a stronger answer when someone asks:
Can we trust this infrastructure right now?
The next generation of cybersecurity
The next generation of cybersecurity will not be only about detecting attacks.
Detection remains necessary, but it is not enough.
The next generation will be about continuously proving that your infrastructure is still trustworthy.
That means proving integrity.
Proving configuration state.
Proving control operation.
Proving audit evidence.
Proving that what is running today still matches what the organization believes it is running.
In the age of autonomous AI attackers, trust is not a static property.
It is a continuous process.
Original LinkedIn post: Peter Veselý on AI, Zero Trust and FILIP.OS.
{"research-audit-evidence":{"title":"Audit Evidence","summary":"Evidence retained to support governance, compliance, security and operational claims, including logs, records, approvals, configuration snapshots, test results, provenance data and review trails.","url":"/research/audit-evidence/","links":[{"title":"NIST Cybersecurity Framework","type":"official-documentation","url":"https://www.nist.gov/cyberframework"},{"title":"ISO 19011 — Guidelines for auditing management systems","type":"standard","url":"https://www.iso.org/standard/70017.html"},{"title":"Regulation (EU) 2016/679 — GDPR official text","type":"regulation","url":"https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng"},{"title":"Risk Management Needs Evidence Infrastructure","type":"my-blog","url":"/blog/risk-management-needs-evidence-infrastructure/"},{"title":"AI-generated content will need more than a label","type":"my-blog","url":"/blog/ai-generated-content-will-need-more-than-a-label/"}]},"research-zero-trust":{"title":"Zero Trust","summary":"Technical and governance profile of Zero Trust as a security architecture methodology based on explicit verification, least privilege, continuous evaluation and the assumption that network location alone should not imply trust.","url":"/research/zero-trust/","links":[{"title":"CISA Zero Trust Maturity Model","type":"official-documentation","url":"https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model"},{"title":"NCSC Zero trust architecture design principles","type":"official-documentation","url":"https://www.ncsc.gov.uk/collection/zero-trust/architecture-design-principles"},{"title":"NIST SP 800-218 Secure Software Development Framework","type":"official-documentation","url":"https://csrc.nist.gov/pubs/sp/800/218/final"},{"title":"NIST SP 800-207 Zero Trust Architecture","type":"standard","url":"https://csrc.nist.gov/pubs/sp/800/207/final"},{"title":"Vibe Coding Can Build Your Application. But Who Builds Its Security?","type":"my-blog","url":"/blog/vibe-coding-builds-applications-who-builds-security/"}]}}