Ingress

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: 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.

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.