How much access should you give a pentester?

There is a moment, right before a penetration test starts, when a system owner gets nervous and starts closing doors. They tighten the firewall, pull back the test credentials, decline to share the architecture diagram, and ask the testers to come at the application cold, the way a real attacker would. It feels rigorous. It feels like the honest way to find out if you are secure. It is, in fact, the single most common way to pay for a test and learn almost nothing from it.

The question of how much access to grant a tester is the most consequential decision you make about an engagement, and it is usually made for the wrong reasons. So let us walk the whole spectrum, from a tester who knows nothing to one who knows everything, and figure out where you actually want to stand.

The spectrum: black, gray, and white

Access in a pentest is usually described as three boxes. In a black box test, the tester starts with nothing but a name or a URL, exactly like an external attacker with no inside knowledge. In a white box test (sometimes called crystal box), they get the keys to the kingdom: source code, architecture documents, admin credentials, and direct access to the developers. Gray box sits in the middle, where the tester gets what a logged-in user or a partially-informed insider would have, typically valid accounts and some documentation, but not the full source.

These are not exotic distinctions. They map directly onto the standards. NIST's SP 800-115, the foundational technical guide to security testing, frames the same idea as overt versus covert and as the amount of information disclosed to the assessor. The Penetration Testing Execution Standard bakes the access conversation into its pre-engagement phase, because the level of access fundamentally changes the test you are buying.

What the industry actually does

If you ask the people who run these engagements for a living, the answer is not subtle. Gray box is the default for application testing, and it is the default because it produces the best test per dollar. In Cobalt's breakdown of the three approaches, the trade is laid out plainly: black box buys you adversary realism but spends most of its budget on discovery, the slow work of mapping a surface from the outside. Gray box skips the guesswork and spends the same days finding vulnerabilities instead. For a fixed engagement length, the lighter-access test finds more.

Black box has its place. If the question you are asking is specifically "how good is my perimeter, and how much can a stranger learn from the outside," then a no-knowledge test answers it. But that is a narrow question, and it is rarely the most valuable one. Most of the risk in a modern application does not live at the front door. It lives three rooms deep, behind a login the attacker will eventually get through one way or another.

Why a test stops at the first locked door

Here is the mechanical reason fuller access matters, and it is the part most people miss. Real systems are built with defense in depth: overlapping controls, each meant to catch what the last one missed. A perimeter firewall, then authentication, then authorization checks, then input validation, then a hardened database. The whole point of layering is that no single control has to be perfect.

A pentest is supposed to validate each of those layers. But a black box tester who gets blocked at the perimeter cannot test anything behind it. They hit the firewall, they cannot get a foothold, and the report effectively says "the firewall held, so presumably everything behind it is fine." That is exactly the inference defense in depth exists to forbid. The second layer might be wide open. The authorization logic might leak every tenant's data to any logged-in user. You will never find out, because the first locked door ended the test.

An unopened door is not a secure door. It is an untested one. The two feel identical right up until someone else opens it.

The fix is not to assume the layers are fine. It is to hand the tester a key to the first door so they can go attack the second, and the third, and the one after that. You are not making the test easier. You are making it complete. A test that validates five controls is strictly more valuable than one that validates the first and guesses about the rest.

The exam anxiety, and why it is backwards

The resistance to opening doors is almost always emotional before it is technical. System owners, especially around older infrastructure, treat the pentest like an exam they might fail. Opening a door, adding the tester's IP to an allowlist, handing over an admin account, all of it feels like giving away points. If the tester gets in because you let them in, did you really pass?

This gets the purpose of the test exactly backwards. A pentest is not a grade on your defenses. It is a search for the vulnerabilities that will hurt you, conducted by someone you are paying to find them before an attacker does. The attacker, crucially, is not on a clock and is not playing fair. They will phish a credential, buy one, or wait for the breach down the street to leak one. The moment you accept that a determined adversary eventually gets a foothold, the honest test is the one that starts from that foothold and asks the question that actually matters: now what?

Every door you open, every account you provision, every IP you allowlist flushes out more real vulnerabilities. The system owner who guards their doors gets a clean-looking report and a false sense of safety. The one who opens them gets an ugly report and a genuinely safer system. The ugly report is the good outcome.

What the standards now say out loud

This used to be a matter of professional taste. It is now written into the standard. The OWASP Application Security Verification Standard, the closest thing application security has to a shared yardstick, took a hard position in its 5.0 release. Its guidance on assessment states that "testing without access to the necessary additional information is an inefficient and ineffective mechanism for security verification," and that black box testing should be "actively discouraged." It recommends documentation- and source-code-led hybrid testing, with full access to the application's developers and documentation, as what is necessary to actually verify the requirements.

The reasoning is concrete. Whole categories of requirement simply cannot be checked from the outside. You cannot confirm that an application avoids logging sensitive data, or that a cryptographic secret is stored correctly, or that an authorization check exists on a code path you never reached, by poking at it blind. The Web Security Testing Guide makes the same point at the level of method: the most thorough results come from combining outside-in testing with a view of how the thing is actually built.

The real ceiling: consent, not courage

So if more access is better, why not always go full white box on everything? Because there is a hard limit, and it is structural, not psychological. It is consent. You can only authorize testing of systems you actually control.

Modern applications are built on a supply chain of other people's systems, and somewhere in that chain, someone says no. Your cloud provider is the clearest example. AWS's penetration testing policy lets you test your own resources on permitted services, but flatly prohibits testing AWS's underlying infrastructure, and still requires prior approval for things like denial-of-service simulation. Your payment processor, your identity provider, your managed database, each comes with its own rules of engagement. A pentest without authorization is not a pentest, it is an intrusion, and consent is the line between the two.

This is why "full access to everything" is a fiction. The achievable goal is not total visibility, it is maximum authorized access: get as far toward the white-box end as the things you are allowed to test will let you, and be honest about where the boundary is. The boundary is a property of your supply chain, not a measure of your bravery.

Assumed breach: starting from inside

The logical endpoint of all of this is the approach that has quietly become the modern default for mature programs: assumed breach. Instead of debating whether an attacker can get in, you stipulate that they already have, hand the tester a foothold, and spend the entire engagement on the question that decides how bad a breach actually gets: how far can they move, how high can they escalate, and what can they reach?

Assumed breach exists because the industry accepted an uncomfortable truth. Perimeters fail. Credentials leak. Most real-world incidents do not begin with a sophisticated zero-day at the edge, they begin with a phished password and a quiet, patient walk through the soft interior. Testing the interior is only possible if you grant the access to reach it. The teams getting the most out of their testing budget are not the ones guarding their doors. They are the ones who open them on purpose, under controlled conditions, so that the walk-through happens with a tester taking notes instead of an attacker taking data.

What good access looks like in practice

Concretely, here is what "lean toward the lighter end of the spectrum" looks like when you are scoping a real engagement. None of these make the test easier. Each one makes it deeper.

1. 01Provision test accounts at every privilege level, including at least one admin, so authorization controls can be tested in both directions rather than guessed at.
2. 02Allowlist the tester's source IPs, so the engagement spends its hours on your application logic instead of on rate limits and bot defenses that you already know work.
3. 03Share architecture and data-flow documentation, so the tester models the system the way it is actually built and reaches the parts that matter.
4. 04Provide source code or read access where the most sensitive logic lives, especially for authentication, authorization, and anything touching money or personal data.
5. 05Test against an environment that mirrors production, so findings are real and not artifacts of a hollowed-out staging copy.
6. 06Write down what is genuinely out of scope (the cloud provider's plane, third-party services you cannot authorize) and why, so the boundary is a deliberate decision rather than an accidental blind spot.

Where this leaves you

The spectrum runs from black box to white box, and the honest advice is to live near the lighter end without pretending you can reach the very edge. Give the tester the credentials, the documentation, the allowlist, and the foothold. Validate every layer, not just the first one. Accept that the supply chain caps how far you can go, and be precise about where that cap is. The reward for opening doors is the only thing a pentest is actually for: finding what is wrong while fixing it is still cheaper than getting breached.

This is the posture Uvy is built around. We take the access you can authorize and the context that comes with it, and we test from inside the way an adversary with a foothold would, then prove the exploitable findings with a working exploit rather than leave you a maybe. The result reads like the report from a team that opened every door you let them open, because that is exactly what it is. If that is the kind of test you want, see how it works.