Apr 28, 2026 - Lina Romero - What the EU AI Act demandsThe EU AI Act classifies AI according to risk. Unacceptable risk is prohibited outright. High-risk AI systems are heavily regulated. Limited-risk systems face transparency obligations. The majority of obligations fall on providers, though deployers carry meaningful obligations too. If your organisation builds AI, buys AI, or integrates AI into operational processes, the Act applies to you. If your systems serve EU users and you are headquartered outside the EU, it still applies to you.For high-risk AI systems, providers must establish a risk management system throughout the system's lifecycle, conduct data governance to ensure training and testing datasets are relevant and representative, produce technical documentation demonstrating compliance, design systems to allow for human oversight, and achieve appropriate levels of accuracy, robustness, and cybersecurity. The Act treats security as foundational to compliance.The compliance gap is a security gapMost organisations approaching the EU AI Act treat it as a governance and legal challenge. They produce AI registers, draft risk classification matrices, and build working groups. That work has value. But it systematically misses the deeper problem.The compliance gap is a security gap. The same reasons that make AI systems hard to secure are the reasons they are hard to govern. You cannot log what you cannot see. You cannot classify what you have not discovered. And you cannot demonstrate to a regulator that your controls are working if those controls only exist as policies on paper.More than 80% of employees use AI tools that have not been approved by their organisation. The AI systems that appear in your register and the AI systems that are actually operating in your environment are different populations. Shadow AI is the dominant reality of how AI is being adopted at scale. Any compliance program that relies on self-reporting to build its inventory has already accepted an undercount of its exposure.The logging mandate is a technical obligationArticle 12 of the EU AI Act requires that high-risk AI systems technically allow for the automatic recording of events over the lifetime of the system. Technically means the capability must be built into or applied to the system itself. Automatic means logs are generated without operator intervention at the moment events occur. Lifetime means from deployment to decommissioning.Article 26 requires automatically generated logs to be retained for a minimum of six months. The organisations that will be best positioned when enforcement begins are not the ones that start building logging infrastructure in July 2026. They are the ones generating six months of compliant, continuous, tamper-evident logs already. If you wait till the enforcement date, you are already behind.Prohibited practices are already enforceableThe prohibited AI practices under Chapter II became enforceable in February 2025. However, the enforcement deadline that most organisations are focused on is August 2026. Compliance with the prohibited practices provisions is a matter of ensuring that systems do not drift into prohibited behaviour. A system that was not designed to manipulate can evolve into one that does. Detecting that change requires continuous behavioural monitoring.‍The GDPR parallelOrganisations that lived through GDPR's May 2018 enforcement date will recognise what is coming. In the months before that deadline, many organisations had produced detailed documentation: data processing registers, privacy notices, breach notification procedures. On paper, they were prepared. In practice, many discovered that their processes did not work, their data maps were incomplete, and their policies had never been technically enforced.The organisations that struggled most under GDPR were those that had treated compliance as a documentation exercise rather than an operational transformation. The EU AI Act presents the same dynamic, with two important differences. 1. Its technical obligations are more demanding than GDPR's2. Its fine structure is more severe. Violations of the prohibited practices provisions can be more expensive than even the most serious GDPR breaches.What closing the gap requiresBridging the EU AI Act compliance gap requires a shift from periodic assurance to continuous control and continuous automated discovery of AI usage across cloud infrastructure, browser-based activity, and application-layer integrations. You need to know about every AI system in your environment, including the ones nobody approved.It requires automated risk classification that maps discovered systems against the Act's risk tiers in real time — not at the next quarterly audit cycle. The Act's obligations follow from classification, so classification needs to be live.It requires centralised logging that captures every relevant interaction with high-risk AI systems automatically, retains logs for the mandated minimum of six months, and makes those logs available for regulatory review on demand.It requires real-time behavioural monitoring that detects patterns approaching prohibited practice thresholds, anomalous outputs that may signal misuse, and adversarial inputs designed to subvert system behaviour.And it requires technical policy enforcement at the point of use. A governance policy that prohibits certain AI uses but has no technical mechanism preventing them is not a control.The question that mattersThe question is not whether you have completed your AI Act checklist. It is whether you could answer a regulator's questions about your AI systems today, and whether the infrastructure you have built is capable of answering those questions six months from now.If the answer is uncertain, the gap is real. And the time to close it is before enforcement, not after.Need help with your compliance? FireTail is here: https://www.firetail.ai/schedule-your-demo

The post Bridging the EU AI Act Compliance Gap – FireTail Blog appeared first on Security Boulevard.

Apr 21, 2026 - Alan Fagan - Most conversations about the EU AI Act focus on August 2026, when obligations for high-risk AI systems become fully enforceable. But Article 5 is already live. The Act’s eight prohibited practices became enforceable in February 2025. Fines of up to €35 million or 7% of global annual turnover apply now. And the infrastructure to act on violations is in place.
For AI providers operating in or serving the EU market, understanding Article 5 is critical.
The EU AI Act takes a risk-based approach to AI governance. The practices represent the EU's judgement that certain applications of AI are incompatible with fundamental rights and democratic values, and the European Commission reinforced that position in the guidelines it published on 4 February 2025, two days after the prohibitions.
The guidelines break each prohibition into cumulative conditions and provide practical examples of what falls in scope and what does not. They are the clearest signal available of how regulators will interpret borderline cases.
The penalty structure reflects the seriousness with which the EU treats these provisions. At up to €35 million or 7% of global annual turnover, violations of Article 5 carry steeper fines than any other category of non-compliance in the Act.
The Eight Prohibitions
1. Subliminal and Manipulative Techniques
AI systems that deploy techniques operating below conscious awareness, or that exploit psychological vulnerabilities, biases, or weaknesses in decision-making to distort behaviour and cause significant harm, are banned.
The prohibition is targeted at systems designed to circumvent rational agency. It does not cover normal personalisation, recommendation engines, or advertising that simply presents persuasive content. The key conditions are that the technique must be subliminal or manipulative, and that it must cause or be reasonably likely to cause significant harm.
In practice, the compliance question for providers is whether their optimisation objectives could drive the system toward manipulative behaviour as a side effect. A recommender system trained purely on engagement maximisation can, over time, evolve into something that exploits psychological patterns in ways that meet the prohibition's conditions. 2. Exploiting Vulnerabilities
AI systems that exploit vulnerabilities arising from a person's age, disability, or socioeconomic circumstances to distort behaviour in ways that cause harm are banned.
The practical example that clarifies this prohibition is an AI advertising tool that identifies users showing signs of financial hardship, through search behaviour, location data, or device signals, and targets them with offers specifically designed to exploit that vulnerability. The Commission's guidelines explicitly name this kind of system as a violation.
This prohibition has direct implications for any AI system operating in consumer finance, healthcare, or social services, where users may be in vulnerable circumstances by definition. The question is not whether the system serves those users, but whether it is designed to exploit their circumstances rather than serve their interests.
3. Social Scoring
General-purpose social scoring of individuals or groups based on social behaviour or personal characteristics, leading to detrimental treatment in contexts unrelated to where the data was collected, is banned when conducted by or on behalf of public authorities.
This is the provision most directly aimed at preventing the kind of surveillance infrastructure that has emerged in certain authoritarian contexts. It applies to public authorities, but it also catches systems that aggregate data across domains in ways that create de facto social profiles affecting access to services, employment, or civic participation.
4. Predictive Policing Based on Profiling
AI systems that assess the likelihood of an individual committing a criminal offence solely on the basis of profiling or personality traits, absent objective and verifiable facts directly linked to criminal activity, are prohibited.
A retail security system that analyses CCTV footage to detect actual suspicious behaviour, such as someone concealing merchandise, is permitted because it reacts to observable actions. A system that flags customers as high risk based on demographic profiling, is not.
5. Untargeted Facial Recognition Scraping
Building or expanding facial recognition databases through untargeted scraping of facial images from the internet or CCTV footage is banned absolutely.
This provision addresses the data acquisition practices used by a number of controversial biometric surveillance providers in recent years. Several of these companies built large-scale facial recognition datasets by scraping billions of images from social media platforms and public web sources without consent. That practice is now illegal in the EU.
6. Emotion Inference in Workplaces and Educational Settings
A range of specialist vendors such as IBM, Microsoft, and Amazon have offered emotion detection capabilities through their cloud platforms and APIs. The global emotion AI market was valued at approximately $7.5 billion in 2024. Many of these tools were being actively evaluated or deployed in employee monitoring, productivity assessment, and remote meeting analysis contexts.
Since February 2025, deploying AI systems that infer the emotional states of individuals in workplaces or educational environments is prohibited in the EU. However, context is determinative. The same AI capability can be permitted in one setting and prohibited in another. Affect recognition technology used for driver safety monitoring in an automotive context has a different regulatory status from the identical technology embedded in an employer's video call analysis platform.
7. Biometric Categorisation by Sensitive Characteristics
AI systems that use biometric data to categorise individuals based on race, political opinions, religious or philosophical beliefs, sex life, or sexual orientation are prohibited.
The narrow exceptions cover the labelling or filtering of biometric datasets that are lawfully acquired, and law enforcement categorisation under strictly controlled conditions.
This prohibition catches systems that providers may not have characterised as biometric categorisation in their original design. Any model that takes facial, voice, or physiological inputs and produces outputs that correlate needs to be assessed carefully against this provision, regardless of the stated purpose.
8. Real-Time Remote Biometric Identification in Public Spaces
The real-time use of remote biometric identification systems in public spaces for law enforcement purposes is prohibited, with narrow exceptions.
Deployment requires a prior fundamental rights impact assessment under Article 27, judicial or independent administrative authorisation before use, and registration in the EU database. In genuine emergencies, use can begin before registration, but registration must follow immediately and the relevant authority must be notified.
This prohibition does not apply to private actors in non-law-enforcement contexts, but it sets a clear precedent for the EU's approach to real-time biometric surveillance in public life.
The Compliance Challenge
Understanding the prohibitions is only the first step. The challenge for providers is ensuring that their systems do not violate prohibitions through optimisation, fine-tuning, or integration with other services.
The European Commission states that deployers bear responsibility for how they use systems, regardless of what the provider's terms of service say. But the design, training, and integration choices that providers make set the boundaries within which deployers operate. Providers who build systems capable of prohibited practices, even if they prohibit those uses, are not fully insulated from regulatory attention if those capabilities are reasonably foreseeable.
Developers need to monitor how systems actually behave in deployment, not just design intent. The Enforcement Reality
Prohibited practices under Article 5 of the AI Act became enforceable on 2 August 2025. No formal enforcement actions have been publicly announced to date, but the architecture is in place and complaints from affected individuals or organisations can trigger investigations at any time.
The enforcement landscape varies by member state. Ireland's proposed implementation assigns prohibited practice enforcement to the Central Bank for financial services, the Workplace Relations Commission for employment contexts, and the Data Protection Commission for others. This means a single organisation with AI systems operating across multiple domains could face scrutiny from more than one authority simultaneously.
What This Means for AI Providers
Article 5 compliance requires ongoing technical visibility into how your systems behave, what data they process, and what outputs they produce. FireTail gives AI providers continuous monitoring and visibility across their deployed systems, capturing the inputs and outputs that compliance evidence requires, detecting patterns that approach prohibited practice thresholds, and generating the audit trail. When the enforcement window closes, that evidence is what separates organisations that were prepared from those that were not.
The prohibited practices provisions are live. The enforcement infrastructure is in place. The guidelines from the Commission have clarified how regulators will interpret the boundaries. The time to build the technical controls that demonstrate compliance is now.

The post Article 5 and the EU AI Act’s Absolute Red Lines – FireTail Blog appeared first on Security Boulevard.

Mar 04, 2026 - - Quick Facts: Shadow AI vs. Managed AIShadow AI is a visibility gap: It refers to any AI tool used by employees that the IT department doesn’t know about. Most companies have 10x more AI tools in use than they realize.Managed AI is a "Paved Path": It uses approved, secure versions of AI where the company not the AI provider owns the data.The biggest risk is data leakage: Shadow AI tools often "learn" from your data, meaning your company secrets could show up in someone else's chat results.Productivity is the driver: This is about getting work done, not breaking rules. Most employees aren't trying to cause trouble; they turn to these unapproved tools simply because they make their daily tasks faster and easier.FireTail bridges the gap: FireTail provides the "eyes" for the security team, identifying hidden AI and putting safety rails around it so businesses can innovate safely.For decades, IT teams have dealt with "Shadow IT." This happened when employees downloaded their own apps or used personal cloud storage because the official company tools were too slow.Today, we are seeing a much faster version of this problem: Shadow AI.As we move through 2026, the gap between companies that control their AI and those that are "hoping for the best" is widening. For a CISO (Chief Information Security Officer), understanding the difference between Shadow AI vs Managed AI is the first step toward securing the enterprise.What is Shadow AI?Shadow AI is any artificial intelligence tool used inside a company without the official "okay" from the IT or security team.Think about a junior analyst facing a tight 5:00 PM deadline to summarize a massive, 50-page legal contract. To save time, they might grab a "free AI PDF Reader" they found on Google, upload the file, and get a summary back in a heartbeat.The Hidden Breach: That "free" tool now has a copy of a confidential contract. Because it’s Shadow AI, the company has no contract with the tool provider. That provider might store the data on an unsecure server or use the text to train their next public model. The company's "secret sauce" is now part of the public internet's brain.What is Managed AI?Managed AI is an intentional strategy. It means the company has chosen specific AI tools, signed security agreements with the providers, and set up "guardrails" to watch what goes in and what comes out.In a Managed AI environment, that same analyst would use an enterprise-grade version of an LLM (Large Language Model). The security team has already checked this tool to ensure that:Data is private: The AI provider is legally blocked from using the company's data to train its models.Access is logged: The company knows who is using the tool and for what purpose.Safety is active: If the analyst tries to upload something they shouldn't (like a customer's credit card number), a security layer blocks it instantly.Why Employees Choose "Shadow" Over "Managed"To fix the problem, we have to understand why it happens. Employees don't wake up wanting to cause a data breach. They use Shadow AI because:Friction: The official company AI might be "too safe," making it slow or hard to use.Speed: It takes two minutes to sign up for a free AI tool and two months to get a tool approved by procurement.Education: Many workers don't realize that "talking" to an AI is the same as "publishing" data to a third party.For a CISO, the goal shouldn't be to "ban" AI. Banning AI just drives it further underground. The goal is to make Managed AI so easy and useful that employees no longer want to use Shadow AI.The 3 Biggest Unmanaged AI Risks for EnterprisesIf you allow Shadow AI to grow, you are opening three specific doors for trouble:1. The "Invisible" Data LeakTraditional security tools (like old firewalls) look for viruses. They don't always recognize a "prompt" as a data leak. If an engineer pastes 1,000 lines of proprietary code into a Shadow AI to find a bug, that code is now "leaked," even though no "hack" took place.2. The Liability TrapIf a Shadow AI chatbot gives a customer wrong advice or makes a promise that breaks the law, the company is still responsible. Without management, you have no way to "fact-check" what the AI is telling the world.3. Intellectual Property LossIf your team uses AI to design a new product or write a patent application on an unmanaged tool, your ownership of that idea could be legally challenged. If the AI "helped" write it on a public platform, who really owns the result?How to Move from Shadow AI to Managed AITransitioning your company doesn't have to be a painful process. It follows a simple three-step path:Step 1: Shadow AI Discovery and VisibilityIt’s impossible to secure a tool if you don’t even know it’s being used on your network. You need a technical way to scan your network and see which AI websites and APIs your employees are visiting.Step 2: Build a "Paved Path" for Your TeamPick a high-quality AI tool and make it available to everyone. If employees have an "official" version of ChatGPT or Claude that is easy to access, they will stop looking for "free" (and dangerous) alternatives.Step 3: Add a Security LayerManaged AI still needs a "security guard." This is a piece of software that sits between the user and the AI. It scans every message for "PII" (Personal Identifiable Information) or secrets and redacts them before the AI ever sees them.‍Mapping Shadow AI Risks to Industry FrameworksTo truly secure AI, CISOs must look beyond simple "usage" and look at specific attack vectors. This is where the OWASP Top 10 for LLM Applications and MITRE ATLAS become essential.Addressing the OWASP Top 10 for LLMsShadow AI is a breeding ground for vulnerabilities identified by OWASP. Without a managed framework, you are exposed to:LLM01: Prompt Injection: In Shadow AI, there is no filter to prevent users (or malicious inputs) from "tricking" the model into revealing backend secrets.LLM02: Sensitive Information Disclosure: This is the primary risk of Shadow AI. Without AI visibility, proprietary data, PII, and credentials are sent to third-party LLMs in plain text.LLM06: Excessive Agency: Unmanaged tools often "over-share" in their outputs. Managed AI allows you to filter these outputs before they reach the user.Utilizing the MITRE ATLAS FrameworkThe MITRE ATLAS (Adversarial Threat Landscape for Artificial-intelligence Systems) framework helps security teams understand how attackers target AI. Shadow AI creates massive gaps in the ATLAS matrix:Reconnaissance: Attackers can identify which unmanaged AI tools your employees use to craft targeted phishing or injection attacks.Exfiltration: Shadow AI provides a "clean" way for data to leave your network. Since the traffic looks like a standard HTTPS request to an AI site, traditional tools may miss the exfiltration of gigabytes of data.ML Model Corruption: If employees use unmanaged tools to build company models, those models could be "poisoned" by untrusted datasets.‍How FireTail Secures the AI JourneyThe difference between Shadow AI and Managed AI is often just a matter of having the right tools. FireTail was built to give CISOs the control they need without slowing down the business.We Find Hidden AI: FireTail automatically identifies every AI model and tool being used across your organization. We turn "Shadow" into "Visible."We Protect Your Data: Our platform sits "inline." This means we see a prompt, check it for sensitive data (like passwords or customer names), and block that data from leaving your network.We Stop Attacks: We look for "Prompt Injections" tricks where people try to "hack" the AI into giving up secrets and stop them instantly.We Make Audits Easy: If a regulator asks, "How are you securing AI?", FireTail provides the logs and proof that your AI is managed and safe.Moving to Managed AI isn't just about security; it's about giving your company the confidence to lead in the age of Artificial Intelligence.Is your company's "secret sauce" being used to train public AI?Don't stay in the dark. Get a FireTail Demo today and see how to bring your Shadow AI into a secure, managed environment.FAQs: Shadow AI vs. Managed AIWhat is the most common example of Shadow AI?The most common example is an employee using a personal ChatGPT account or a free online "AI writing assistant" to handle company documents. FireTail helps you find these tools and bring them under company control.Why is Shadow AI more dangerous than regular Shadow IT?Regular Shadow IT just stores data, but Shadow AI "learns" from it and can repeat it to other users. FireTail prevents this by blocking sensitive data before it reaches the AI's training bank.Can I just ban AI to solve the Shadow AI problem?Banning AI usually fails because employees will use it on their personal phones or home computers to get work done. FireTail provides a better way by making AI safe to use so you don't have to ban it.Does Managed AI protect me from legal issues?Managed AI helps significantly because it provides a "paper trail" of what the AI said and what data it used. FireTail adds an extra layer of protection by monitoring AI outputs for policy violations.How does FireTail discover Shadow AI?FireTail monitors your API traffic and network connections to identify calls to known AI providers. This gives you a real-time map of every AI tool being used in your company.What is "Prompt Redaction" in Managed AI?Prompt Redaction is the process of automatically "blacking out" sensitive info like names or API keys before they are sent to the AI. FireTail does this automatically, so your employees can use AI without accidentally leaking secrets.How fast can you switch from Shadow AI to a Managed system?If you use the right monitoring tools, you can usually spot your biggest security gaps in just a few days. FireTail helps speed this up by providing instant visibility into your current AI landscape.‍

The post Shadow AI vs Managed AI: What’s the Difference? – FireTail Blog appeared first on Security Boulevard.

Feb 27, 2026 - Alan Fagan - The "OpenClaw" crisis has board members asking, "Could this happen to us?" The answer isn't to ban AI agents. It's to govern them.
By now, the dust is settling on the OpenClaw (aka MoltBot) incident. The technical post-mortems (including our own) have been written, the exposed ports have been closed, and the 1.5 million leaked API keys are being rotated.
But for the Enterprise CISO, the real work is just beginning.
This incident has shifted the conversation about "Agentic AI" from a future roadmap item to an immediate risk management priority. Your Board and Executive Team are likely asking two questions:
Are we vulnerable to an OpenClaw-style breach?
Should we just ban these agents entirely?
The answer to the first is "likely yes." The answer to the second is "absolutely not."
In this strategic guide, we outline why the "Ban" approach will fail, and how to implement a governance framework that allows your organization to harness the power of autonomous agents without inviting the chaos of the "Wild West."
The "Ban" Fallacy: Why You Can’t Block Your Way to Safety
In the wake of a security crisis, the reflex is often to lock everything down. Network teams might block traffic to pypi.org or github.com. Endpoint teams might block processes named clawdbot.
But "Shadow Agents" are resilient.
They are open source: If you block the OpenClaw repo, employees will fork it, rename it, and deploy it under a benign name like my-jira-helper.
They are productive: High-performers use these tools because they work. An agent that can autonomously debug code or reconcile financial spreadsheets saves hours of human time. If you ban them without providing a secure alternative, you aren't removing the risk - you are just driving it underground.
When employees hide their tools, you lose visibility. And in the world of autonomous agents, lack of visibility is worse than having no controls at all.
The "Wild West" vs. The Managed Environment
The OpenClaw disaster wasn't caused by AI itself; it was caused by a total lack of governance.
The software was designed with a "Wild West" philosophy: the agent had full root access, trusted every instruction, and broadcasted its interface to the world.
To secure the enterprise, we don't need to stop the agent; we need to change the environment it operates in.
Comparison: OpenClaw vs. A FireTail-Governed Agent
Feature
The "Wild West" (OpenClaw)
The FireTail Managed Environment
Visibility
Deployed at all. Developers install and run it wherever, without your team’s knowledge.
Governed and seen. FireTail tells you what devices and users have OpenClaw and OpenClaw-initiated connections.
Data Privacy
Raw Exfiltration: Sends full confidential documents to public LLM APIs.
Real-Time Redaction: PII and secrets are detected and can be blocked before the prompt leaves the network.
Audit Trail
Ephemeral: Logs are stored in local text files or not at all.
Immutable: Every prompt, and external response is logged centrally for compliance and detection and response defenses.. The FireTail Strategy: Total AI Governance
The path forward is to wrap your organization in a layer of Policy Enforcement. This is the core of the FireTail platform.
1. Define the "Safe Lane"
Establish policies that define what is allowed.
Policy Example: "Agents may not communicate with LLMs on our deny list”
Policy Example: "Agents may browse the web for research, but are blocked from using or uploading PII."
2. Enforce PII & Secret Redaction
One of the biggest risks with OpenClaw was that it could read .env files and send keys to an external server. FireTail acts as a firewall for LLM prompts. If an agent attempts to send an AWS Secret Key or a Customer SSN to an LLM, FireTail can detect the pattern and block the request instantly.
3. Centralized Observability
You cannot govern what you cannot see. FireTail provides a "Control Tower" view of every agentic interaction in your enterprise. If a developer's agent suddenly starts making 5,000 API calls per minute (a sign of a loop or an attack), you can know about this and respond immediately.
The CISO's Script
When your Board asks about your strategy for Agentic AI, here is your answer:
"We are not banning AI agents, because that would only create a hidden shadow agent ecosystem of unmonitored tools. Instead, we are implementing an AI Security Platform (FireTail) that forces these agents to operate within strict guardrails. We will allow the productivity, but we will technically enforce the security."
OpenClaw was a warning. It showed us the fragility of unmanaged agents. But it also showed us the future of work. More and more agents are coming. It’s only a question of time. The organizations that win won't be the ones that hide from this technology - they will be the ones that build the safest roads for it to run on.

The post OpenClaw Insights: A CISO’s Guide to Safe Autonomous Agents – FireTail Blog appeared first on Security Boulevard.