# Ingress

> One front door for internal AI applications, instead of a tunnel, a share link, and a forwarded port per team.

Source: https://brocs.fyi/control/ingress/
Part of the surface: C · Control. Keep a hand on the wheel.
Framework: BROCS (Build, Run, Observe, Control, Secure), brocs.fyi. CC BY 4.0, attribute to brocs.fyi.

---

## The Control surface

- Configuration: declarative, versioned, reviewed, reversible
- Ingress: one front door for internal AI apps
- Identity: SSO by default, external access without VPN sprawl
- Storage and backups: retention, lifecycle, restore drills
- Routing: model and provider routing, pinning, failover
- Remote access: work reaches the data instead of the data reaching the laptop


Ingress is how a request reaches an internal application, and where authentication,
authorization, and logging get applied. It is a solved problem that AI adoption reliably
unsolves, because the shortest path from a working prototype to a colleague trying it is
a public URL.

## How the sprawl happens

Someone builds a useful tool. They need to show it to three people. The options are the
platform's ingress process, which takes a few days, or a tunnel from their laptop, which
takes ninety seconds.

Three months later that tunnel is load-bearing, it runs from a machine under a desk, it
has no authentication beyond an unguessable hostname, and the person who set it up has
changed teams. Multiply by the number of enthusiastic builders in your organization.

The lesson is the one from [Build](/build/idea-to-production/): the sanctioned path has
to be faster than the workaround. An ingress request that resolves in a day loses to a
tunnel that resolves in a minute, every time, regardless of policy.

## What one front door gives you

Routing every internal AI application through a single ingress layer means these are
solved once instead of per application:

- **Authentication.** SSO by default, with no application implementing its own login.
- **Authorization.** Group-based access enforced before the request reaches the app.
- **Logging.** Who reached what, when, from where. Frequently the only access record
  that exists for a tool built in an afternoon.
- **Rate limiting.** Both abuse protection and a spend control, since every request
  behind it costs money.
- **TLS and certificates.** Not per team, and not expired.
- **A kill switch.** One place to cut off an application that is misbehaving, without
  finding whoever owns it.

The kill switch matters more than it sounds. When an internal tool starts doing something
wrong, the response time is bounded by how quickly you can stop it reaching users.

## Public exposure is a different decision

Internal ingress should be self-service. Public exposure should not be.

The moment an AI application is reachable by people outside the organization, several
things change at once: the input is untrusted, the output is a public statement by your
company, and the cost is driven by strangers. All three need a deliberate decision by
someone accountable, plus rate limiting, abuse handling, and a review of what the
application can reach.

Make internal easy and public a gate. Most organizations get this backwards by having one
process for both, which is either too slow for internal use or too loose for external.

{{< failure id="air-canada-chatbot" >}}

## Partners and contractors without VPN sprawl

The requirement that breaks naive designs is external collaborators who need access to
some internal applications and nothing else.

The pattern that works is federation at the ingress layer rather than accounts in your
directory: the partner authenticates against their own identity provider, your ingress
maps that to a scoped role, and access is time-bound. No VPN, no guest accounts that
outlive the engagement by three years.

The pattern that does not work, and is extremely common, is a shared credential in an
email.

{{< aside title="How zero trust thinks about this" >}}
The zero trust position is that network location is not authorization, and every request
gets authenticated and authorized on its own. Internal AI tools are a good test of whether
you actually believe that: they are usually built quickly, hosted internally, and treated
as safe because they are behind the perimeter. An identity-aware proxy in front of every
internal app, including the ones built by non-engineers, is the practical expression of
the idea.
{{< /aside >}}

{{< checklist >}}
- How many internal AI applications are reachable right now, and through what?
- How long does it take to get a hostname with SSO in front of it?
- Is there a tunnel running from someone's laptop that people depend on?
- Can you cut off one application in under five minutes without finding its owner?
- What is the process for making an AI application public, and who signs it?
- How do external collaborators reach the applications they need?
{{< /checklist >}}