Why Enterprise Access Requests Should Be Filed on Day One

Your pilot works on your laptop. Then it meets the customer's network, and the schedule is set by a firewall rule, a service account, a VPN profile and an SSO approval, all sitting in other teams' queues. Enterprise access requests are the slowest dependency in most AI rollouts, and the fix costs a few hours: file every one of them in the first days of the engagement.

Why enterprise access requests set your real schedule

You control model quality. You do not control the network team's change window, and that approval moves at the speed of their queue.

These requests hurt for two reasons. They block each other: the allowlist has to exist before you can test the model connection, and the service account has to exist before you can test the data pull. And they stay invisible until you are stuck, because nobody writes "wait for firewall change" on a project plan until it is the reason the demo slipped.

Picture week three: the retrieval pipeline is built, the evals pass on sample data, and the service account request you filed that morning is sitting behind someone else's access review. File on the day you need it and the wait lands on your critical path. File on day one and the wait runs in parallel with everything you build.

Build a day-one checklist ordered by lead time

Order the list by how long approval usually takes at this customer, not by when you will need it. Ask your sponsor which teams are slow. They know. Here is a starting point:

# day-one-access-checklist.yaml
# Longest typical lead time first. Confirm the order with your customer sponsor.
- request: Security and vendor risk review (questionnaire, data terms, model provider approval)
  customer_owner: <security contact>
  blocks: production go-live
- request: Outbound firewall allowlist (model API hostnames, package and container registries)
  customer_owner: <network team contact>
  blocks: every call from the customer environment to a model
- request: Private connectivity (VPN, private link or peering) to the cloud environment
  customer_owner: <network team contact>
  blocks: integration with internal systems
- request: Cloud accounts or projects, plus quota increases for GPUs or high token volumes
  customer_owner: <cloud admin contact>
  blocks: load tests, deployment
- request: Service accounts and roles for the app, the CI pipeline and data readers
  customer_owner: <IAM team contact>
  blocks: retrieval pipeline, evals on real data
- request: SSO app registration (SAML or OIDC) for the end-user interface
  customer_owner: <identity team contact>
  blocks: pilot with real users
- request: Read-only access to one representative data source, plus sample data
  customer_owner: <data owner>
  blocks: realistic evals
- request: Team access (VPN profiles, repo, ticketing, laptops or badges)
  customer_owner: <sponsor>
  blocks: the team itself

The blocks field matters most. It turns "we are waiting on a ticket" into "we cannot test retrieval", which is a sentence a sponsor can escalate. Delete lines that do not apply and add the ones your customer is known for.

Track every request with an owner, SLA and blocked work

A checklist you file once and forget is a wish list. Review it in every weekly sync, adding the date you filed each request, its SLA and its status.

The SLA is the number the owning team commits to. If they do not have one, write down the date they will give you a status update. A request with no date on it is the one that quietly stalls.

Answer "we don't know the requirements yet" with a broad but reviewable request

This is the strongest objection, and it is partly right. On day one you do not know which hostnames, tables or roles you will end up using.

So ask for the broad set, but make it reviewable. Broad means covering the plausible options: two model endpoints instead of one, read access to a schema instead of a single table. Reviewable means every item is named and justified: exact hostnames instead of wildcards, port 443, read-only, non-production, with an expiry date. Security teams reject open-ended asks, but they approve what they can read in two minutes. Reviewers think in least privilege, and the AWS IAM best practices are a fair model for wording the justification.

# firewall-request.yaml (paste into the customer's change ticket)
summary: Outbound HTTPS from the AI pilot environment to model and package endpoints
environment: dev (non-production), no customer data in scope yet
source: <pilot-subnet-cidr>
destinations:
  - host: <model-provider-api-hostname>
    port: 443
    purpose: LLM inference calls
  - host: <comparison-model-api-hostname>
    port: 443
    purpose: side-by-side model comparison during evals
  - host: <package-registry-hostname>
    port: 443
    purpose: dependency install at build time
justification: pilot starts <date>; we will narrow to the endpoints actually used and expire the rest
review_by: <date>

Named destinations, a stated purpose and a review date make a firewall allowlist that survives review, and narrowing an approved rule later is usually cheaper than winning the first approval.

The honest cost: some approvals will go unused, and someone will ask why you filed them. Withdraw them with a note. Keep day-one requests to dev and sandbox environments, because asking for production data access in week one makes reviewers nervous and slows everything else down.

Gotchas

• Some teams only accept requests from a named customer employee, so ask your sponsor to file or co-sign.
• Approvals can expire. Put the expiry dates in your tracker.
• A granted allowlist is not a working connection. Test it the day it lands, not the day you need it.

File the first three tickets at your next kickoff

At the next kickoff, put the checklist on screen before the architecture slide. Assign a customer owner to each line and file the first three tickets, security review, firewall allowlist and service account request, before the meeting ends.

A model you cannot reach, with an identity that cannot read data, is still a demo, so the approvals you file this week decide when you actually ship.