Frequently Asked Questions (FAQ)

I already have web firewalls and other perimeter controls. Why bother with taming my chaotic runtime?

The answer lies within. We spend our lives trying to create a perfect world around us - “If only this were to work perfectly, I could do my best.” However, our personal best comes from being self-aware. Regardless of how the outside world is impacting us and reacting to it, we should be proactive with an internal locus of control. We can either measure everything around us or measure how we are internally being impacted.

Get your internal temperature. Think inside-out. Organize your runtime, it’s your own backyard. Spot thieves by introspecting within. Self-organize your cloud-native runtime with Araali.


An outside-in mindset is a chasing game. Stop playing catchup!

How is Araali different from Zero Trust Network Access (ZTNA)?

Zero trust starts with announcing the perimeter as dead. There is some common ground there. However, zero-trust can vary significantly in form and rigor.


The first variant is of the user kind (ZTNA). It's about authenticating your users and giving them least-privileges. This is the camp sounding the death knell to VPN and on-prem firewalls (the need to bring in all traffic on-prem for security). But is the perimeter truly dead? It’s just more managed as a software-defined perimeter (SDP, SASE). Moreover, with ZTNA, who did you protect? The user? The services they got access to? Or, the services the user did not get access to?

The second form is stricter and more comprehensive, thus making it more difficult to implement. If the object of protection was service, not user, what would be the threat vector? Apps and programmatic access are a more serious threat to unauthorized service access. So, the focus should be to protect services - inside out, as accessed by apps. User access already happened at the software-defined perimeter. By design, services are exposed only to apps on a need to know basis, and never to users or to their devices.

How about using MTLS for service access control?

There is this MTLS camp for service protection, and many find their peace away from zero-trust there. But that only gives you data in-flight encryption (man-in-the-middle protection). Men at either endpoint get a full bypass.


Where is last-mile authentication? Dishing out certificates without authentication is not very different from old school password play. Where is authorization and policy discovery? Where is the audit for service access? Burnt into services?


There could be gaps that Araali can address for you - single-click, zero-touch, no-harm!

Will I have to change my apps?

Araali is completely application transparent. Not only can it work with your apps without any change, but it can also handle third-party and open source apps written in any language.

I already have zero-trust, do I still need to bother with Araali?

Historically speaking, zero-trust was a painful journey. Congratulations on having the courage to be an early adopter. However, runtime chaos has taken a whole new dimension recently with "push on green," increased internal chatter from microservices, and elastic scale that creates ephemeral and dynamic instances in your runtime.

If zero-trust was hard, keeping it up to date will be harder. We've tried to make it self-organizing, and self-adapting. Give it a try to see the difference.

How long does it take to derive value?

We require no configuration to get started. That's what makes us zero-touch. Without any explicit input, see your runtime benefit from self-organization instantly.

Will this affect performance?

We are powered by Linux's newest superpower: eBPF. That's what makes us extraordinarily performant and non-disruptive. We will not touch, slow down, or modify any packets, nor will we ever look inside your payloads. We only pull the meta-data that is essential to infusing self-organization into your runtime. A lot of this information is already available in the public domain and made accessible through readily available OSINT tools

Is this an agent?

It is more than just an agent. Araali is a distributed firewall for least privilege service access that is SaaS managed. It runs as a daemonset in your Kubernetes cluster. That's what makes it single-click: kubectl apply -f araali.yml

SaaS makes it multi-cluster and multi-cloud out of the box. Get the essential pieces on-prem with a single click and leave the security software installation and monitoring to us.

Aren't third-party agents inherently unsafe?

Software is eating the world, and agents are the vehicle of choice for delivering modern software. Software has bugs - it can be your software or third party agents. The important thing is to have runtime controls in place so you can deal with trouble - whether it emanates from code you write, a third party writes, or comes from their own software supply chain. It's the absence of controls, not the origin of software that matters. Build versus buy is a business decision, not a panacea for better security.

How do I feel safe when using third-party agents?

Monitor your monitors. There is a lot of monitoring software that we use and for good reasons. Often these monitors have escalated privileges too - because they exist to monitor your runtime. It becomes even more important to monitor your monitors, given their privilege. Also, these monitors should themselves practice least-privileges, and you should be able to hold them to that. This is not so much about where it comes from - homegrown, third party, even open source.

At Araali, we monitor your complete runtime - whether it’s your code, or third-party, or even our own software. That is why we can hold them to least-privileges out of the box. That is also why we don’t need to push out new signatures to detect the SolarWinds infection. We can bubble up privilege escalation of any software that is part of your runtime.

Innovate without fear. But don’t forget to monitor, especially your monitors.



Icons made by Flaticon


39812 Mission Blvd. Suite 224
Fremont, CA 94539 USA

  • White LinkedIn Icon
  • White Twitter Icon