How Shinobi Security gets access to apps with internal DNS names or redirect flows to run AI agents

Shinobi Security is like renting a ethical hacker—but this one's AI and never sleeps, while also being trained alongside the devs that built the app they're testing.

Shinobi offers their customers teams of AI agents. These agents collaborate, escalate privileges, chain vulnerabilities, and think like real attackers, because their creators used to be ones.

Developers treat these agents just like they would security teammates. As soon as developers create a new version of their apps, they prompt the agent with a bit of context about the app and how it is supposed to work, and the agents get to work hacking at the new app and attempting to find vulnerabilities.

Shinobi flips the script of most security tools: instead of drowning you in dashboards and warnings, it proves your vulnerabilities with working exploits. You don’t get a random alert. You get told, “You will get hacked unless you fix this, and here’s how.”

How does Shinobi get access to customers' apps?
Customers didn’t want even Shinobi's AI hackers testing on production apps, so they often requested that Shinobi agents work within the confines of staging or dev environments. Shinobi’s product works wonderfully once it’s set up in a customer’s environment, but customer environments can be tricky.

Applications often required custom headers or authentication credentials just to honor requests from Shinobi's agent, which meant they would have to customize their solution for every nuance and oddity of those dev/staging environments.

Shinobi Security selected ngrok to create public endpoints for local machines within their customers' networks. ngrok's flexibility and ease of configuration were pivotal in their decision—Varun was able to get a PoC up and running in minutes.

Implementing ngrok reduced the setup time to run penetration tests on their customers' apps to just 15 minutes.

Even through ngrok simplified how Shinobi accessed customer networks and shrunk the time-to-test, they sometimes ran into other hurdles.

For example, some agents would need access to an app within a customer’s network that had internal DNS names or redirect flows that would break in an outbound tunnelled environment (e.g., 302 redirects to internal.corp.local).

To solve for this common issue (that devs usually tie a bunch of different tools together to fix) Shinobi wrote a unique policy unique traffic policy to intercept and rewrite 302 redirect headers coming from customer apps, preserving UX and agent behavior.

on_http_request:
  - actions:
      - type: add-headers
        config:
          headers:
            host: 127.0.0.1
      - type: forward-internal
        config:
          url: https://service-01.customer-abc.internal

on_http_response:
  - expressions:
      - "res.status_code == 302"
    actions:
      - type: set-vars
        config:
          vars:
            orig: "${url.parse(res.location).path}"
      - type: remove-headers
        config:
          headers:
            - Location
      - type: add-headers
        config:
          headers:
            Location: "$NGROK_DOMAIN/${vars.orig}"

As they expand their customer base, Shinobi also imagines writing other policies for ensuring their AI agents can properly authenticate themselves even in dev/staging environments.