Agentic AI Penetration Testing External Attack Surface Management Continuous Automated Red Teaming

FireCompass Expert & Continuous Automated Red Teaming Consultant

I work across the FireCompass platform, covering Continuous Automated Red Teaming, External Attack Surface Management, Continuous Threat Exposure Management and Penetration Testing as a Service. Because I hold the OSCP and still do manual testing, I can tell you where a continuous outside-in platform genuinely replaces work you are paying for today and where it does not, which is a more useful conversation than a datasheet walkthrough.

Discuss Your Requirements VAPT Services

Agentic AI Penetration Testing for Web and APIs

Outside-in discovery, no asset list required
Continuous attack playbooks, not a yearly snapshot
UAE & GCC regulatory context

What is FireCompass?

FireCompass describes itself as an agentic AI penetration testing platform for web and APIs. The label is accurate, but it undersells the thing that actually distinguishes the product, which is the direction it works in. Almost every security testing tool you have bought before starts from a list: you hand it a range of addresses, a set of hostnames or an inventory export, and it tests what you gave it. FireCompass starts from the outside in. It discovers your organisation's internet-facing footprint the way an attacker performing reconnaissance would, using public signals rather than your inventory, and then runs its attack playbooks continuously against whatever it found. That is the difference between a scanner you point at known assets and a system that first works out what you actually expose.

The platform brings four capabilities together under one external viewpoint. Continuous Automated Red Teaming, usually shortened to CART, runs attacker playbooks against the discovered surface on an ongoing basis rather than as a scheduled event. External Attack Surface Management, or EASM, is the discovery and inventory layer that makes the rest possible. Continuous Threat Exposure Management, CTEM, is the programme wrapper: the loop of scoping, discovery, prioritisation, validation and mobilisation that turns findings into work somebody actually completes. Penetration Testing as a Service, PTaaS, is the delivered testing model layered on top. The same external viewpoint is then applied to supply chain and third-party risk, which is a natural extension, because the way you assess a supplier from outside is the way you assess yourself from outside.

What makes the outside-in approach worth explaining properly is what it surfaces. Discovery routinely finds shadow IT that a business unit stood up without telling anyone, forgotten subdomains left behind by a campaign or a migration, exposed services that a firewall change quietly made reachable, and assets that appear on no inventory anywhere in the organisation. Those are the assets nobody is patching, nobody is monitoring and nobody has in scope for the annual test, which is precisely why they are the ones attackers find first. Running attack playbooks continuously against that discovered surface, instead of against a list you supply, closes the gap between what you think you expose and what you actually expose. That gap is the whole product.

Official Product Portfolio

Where I Can Help

Outside-in programmes succeed or fail on scope, attribution and what happens to the findings afterwards, not on the technology. These are the areas I cover across the FireCompass platform.

External Discovery & Asset Attribution

Setting up discovery so it finds the footprint nobody recorded, then dealing properly with what comes back. Seed domains and brand identifiers, triage of every newly discovered asset, and a named owner assigned before anything enters testing scope. Discovery infers ownership rather than proving it, so anything ambiguous stays out of scope until a human confirms it.

External Attack Surface Management Rollout

Turning a discovery result into a maintained inventory. Deduplicating against the asset records you already keep, reconciling what EASM found with what the CMDB claims, agreeing what a legitimate exposure looks like for your business, and building the routine that reviews new assets every week instead of once when the platform was bought.

Continuous Automated Red Teaming Cadence

Deciding what runs continuously, what runs on a trigger and what still needs a human. Playbook selection against the discovered surface, a run frequency that reflects how fast your estate actually changes, out-of-cycle runs after a major release or a newly published exploit, and rules of engagement written down before the first run rather than after the first complaint.

CTEM Programme Design

Building the loop rather than buying the tool. Scoping what the programme covers, running discovery, prioritising by real exposure instead of raw severity counts, validating that a finding is genuinely reachable from outside, and mobilising fixes into a queue an infrastructure team will work through. Continuous exposure management fails when nobody owns the mobilisation step.

PTaaS Scoping & Assessor Evidence

Getting the testing model right on paper. What is in scope for web and API testing, what the deliverable actually contains, who signs it, and whether that satisfies the specific clause your assessor is asking about. Reporting shaped for the evidence NESA, CBUAE, DESC and PCI DSS requirement 11 assessors expect to see, with the independence question settled in writing beforehand.

Supply Chain & Third-Party External Risk

Applying the same external viewpoint to the suppliers who connect into your environment. Assessing a vendor the way an attacker would see them, deciding which suppliers justify continuous monitoring rather than an annual questionnaire, and combining outside-in evidence with a ratings approach so the third-party conversation rests on observation instead of self-assessment.

Why FireCompass for UAE Organisations?

The regional argument for outside-in discovery is structural rather than technical. UAE groups tend to run sprawling estates: multiple legal entities, presences across several free zones, businesses acquired over the years and never fully integrated, and digital work commissioned directly by business units that never passed through IT. Every one of those is a way for an internet-facing asset to exist without appearing on anybody's inventory. Unknown external assets are not an edge case in this market, they are the normal condition, and no amount of scanning a list you already hold will surface them. That is the specific problem an outside-in platform is built for.

The second argument is about whose view counts. An external attacker view is exactly what a regulator, an auditor or an acquirer doing technical due diligence sees first, because it is the only view available to them without your cooperation. NESA expects technical vulnerability management with evidence that findings are actually addressed. CBUAE pushes regulated financial institutions towards demonstrable and repeated testing rather than an annual tick. DESC in Dubai, the regimes in ADGM and DIFC, and the federal PDPL all converge on the same assessment question: can you show the control worked, not merely that you bought it. PCI DSS requirement 11 is the most explicit of the set, mandating penetration testing at defined intervals and after significant change, and that phrase about significant change is where an annual-only programme falls down. Knowing what you expose, continuously, is the first thing every one of them is really testing.

Now the part a vendor page usually leaves out. An outside-in platform sees the external surface, and that boundary is real. It says very little about internal segmentation, about insider risk from someone who already holds legitimate access, or about what happens after initial access, because none of that is visible from outside by design. It complements internal testing rather than replacing it, and a programme that buys one while assuming it covers the other has a gap it cannot see. The second honest caveat is attribution. Discovery infers ownership from public signals, so it will surface assets that turn out to belong to a sister company, a marketing agency, a shared hosting neighbour or a supplier. Someone has to review that list before anyone acts on it, because testing something you do not own is a legal problem rather than a paperwork one. I hold the OSCP, which means I will tell you where continuous automation substitutes for a human tester and where it does not. For the wider picture, see my VAPT and penetration testing services.

Asset lists you supply before discovery starts

Capabilities in one view: CART, EASM, CTEM, PTaaS

Req 11

PCI DSS clause mandating regular pentesting

Outside

The view a regulator or acquirer sees first

Available for engagements

Talk to a FireCompass Expert

Whether you are trying to establish what your group actually exposes to the internet, replacing a once-a-year external test with something continuous, or working out what an outside-in platform does and does not cover for your regulator, I can help.

Free initial scoping call
UAE & GCC regulatory context
Honest view on external versus internal coverage
Asset attribution reviewed before anything is tested
OSCP-certified offensive security background

Get in Touch

Frequently Asked Questions

The difference is the starting point, and it matters more than any feature comparison. A scanner tests what you tell it to test. You supply a range of addresses or a list of hostnames, it works through them, and it returns findings about those assets. If something is missing from the list, the scanner is silent about it, and silence reads exactly like a clean result. FireCompass works from the outside in. It first discovers what your organisation actually exposes to the internet, the way an attacker doing reconnaissance would, and then runs attack playbooks continuously against that discovered surface. The practical outcome is different in kind rather than in degree: a scanner tells you the state of the assets you already knew about, while an outside-in platform is trying to answer the harder question of what you expose that nobody in IT has written down. Most organisations already run a scanner. Very few can produce a defensible answer to the second question.

Treat that as a question for your assessor rather than for a vendor page, and settle it in writing before you buy. PCI DSS requirement 11 calls for penetration testing at defined intervals and after significant change, and several UAE frameworks expect testing performed by a party independent of the organisation being assessed. Penetration Testing as a Service delivered by the vendor is a different arrangement from a platform you own and operate yourself, so the independence question can have a different answer depending on which part of the offering you are buying and who signs the report. What the continuous side genuinely fixes is drift. A once-a-year test validates the estate once, and then the estate changes for eleven months while nobody tests it again. Continuous discovery and continuous attack playbooks cover that gap, so the formal assessment starts from a much cleaner baseline and the human tester spends the engagement on the interesting problems rather than on findings you could have caught yourself.

Everything that happens after the perimeter. An external view is very good at the question of what an attacker can reach and what they could do to gain a first foothold, and it says very little about what happens next. Internal network segmentation, lateral movement between internal subnets, privilege escalation inside the domain, insider risk from someone who already holds legitimate access, and the blast radius of a compromised workstation are all outside its field of view by design. That is not a criticism of the product, it is what outside-in means. The right framing is complementary. FireCompass covers the external surface and its exposure continuously, and you still need internal testing, whether that is automated internal validation or a manual engagement, to understand what an attacker does once they are inside. Buying one and assuming it covers the other is the most expensive misunderstanding in this category.

Carefully, and with a named human in the loop before anyone acts on the list. Automated external discovery works by inference: shared infrastructure, certificate data, naming patterns, hosting relationships and registration records all point towards ownership without proving it. In a UAE group with multiple entities, free zone registrations, joint ventures and acquired businesses, that inference is right often enough to be valuable and wrong often enough to be dangerous. Some of what appears will belong to a sister company, a marketing agency that registered a campaign domain, a shared hosting neighbour, or a supplier. So build a review step into the process: every newly discovered asset gets triaged and attributed to a named owner before it enters scope for testing, and anything ambiguous stays out of scope until ownership is confirmed. Testing something you do not own is not a paperwork problem, it is a legal one. The upside is that the triage itself is valuable, because the unexplained assets that turn out to be genuinely yours are usually the most interesting findings in the whole exercise.

Outside-In Is One Half of the Picture

FireCompass works from the internet inwards and is strongest on the question of what you expose and what an attacker can reach without any help from you. Pentera works from a position inside the network and is strongest on what happens after a foothold. RiskRecon rates suppliers from the same external viewpoint, which makes it a fair comparison point for the third-party side of the conversation. These are complementary positions rather than competing ones, and the shortlisting mistake I run into most is assuming any one of them covers the others.

Pentera RiskRecon

Basim Ibrahim, FireCompass Consultant in Dubai

If you are searching for a FireCompass consultant in Dubai, a FireCompass implementation partner in the UAE, or an external attack surface management expert for GCC deployment, you have found the right person. I am Basim Ibrahim, an OSCP-certified cybersecurity presales and technical consultant based in Dubai, working across the FireCompass agentic AI penetration testing platform, including Continuous Automated Red Teaming, External Attack Surface Management, Continuous Threat Exposure Management and Penetration Testing as a Service.

I provide end-to-end FireCompass deployment services in Dubai and the UAE, from evaluation and proof-of-concept through to discovery scoping, asset attribution review and the remediation programme that follows. Whether you need continuous automated red teaming in the UAE to cover the gap between annual assessments, external attack surface discovery that finds the shadow IT and forgotten subdomains your inventory never recorded, a continuous threat exposure management programme designed as a repeatable loop rather than a one-off project, penetration testing as a service for web applications and APIs, or supply chain and third-party risk assessed from the outside in, I can deliver it.

Based in Dubai with hands-on experience across UAE and GCC enterprise environments, and comfortable mapping exposure evidence to NESA, CBUAE, DESC, ADGM, DIFC, PDPL and PCI DSS requirement 11 expectations. Because I hold the OSCP and still do manual testing, the advice covers both sides of the line, including where an external view stops and internal testing has to take over. I also work with Pentera for internal validation and RiskRecon for third-party ratings, and the full picture is on my VAPT services page.