A contractor needs one application for six weeks

The request, step by step

1. Record who vouches for her

   The engagement record holds the sponsor, the scope and the end date, and the guest identity is created from it rather than beside it. She authenticates as herself with a second factor. There is now one place that answers who authorised this access and when it should stop.

   • Context: Engagement record to Policy engine, “Sponsor, scope and end date”
   • Context: Identity provider to Policy engine, “Guest identity and its expiry”
   • Context: Build-tooling contractor to Identity provider, “Sign-in and a second factor”

   Emphasised at this step: Identity provider.

2. Grant the minimum, and name it

   She starts work on her own laptop and reaches the broker without a client, and the broker presents the request for a decision. The grant names one console rather than the environment it lives in, so a genuine scope change has to be asked for instead of arriving free.

   • Request: Build-tooling contractor to Contractor's laptop, “Starts work on her own laptop”
   • Request: Contractor's laptop to Access broker, “Clientless session to the broker”
   • Request: Access broker to Policy engine, “Request presented for a decision”

   Emphasised at this step: Access broker.

3. Take the device claim for what it is

   Her laptop reports posture that the enterprise cannot verify, so the claim is recorded as an assertion and the verdict changes what the session may do rather than pretending the device is trusted. The work happens inside an isolated, inspected session.

   • Context: Contractor's laptop to Policy engine, “Device posture: asserted, not measured”
   • Request: Policy engine to Session and data controls, “Verdict and the controls it requires”

   Emphasised at this step: Session and data controls.

4. Broker the session instead of routing it

   The broker connects outward to the named console, which then reads its own artefacts. No network route is created, so reachability never becomes transitive and nothing else on the estate is one connection away.

   • Request: Access broker to Build pipeline console, “Brokered session to one console”
   • Request: Build pipeline console to Build artefacts, “Console reads build artefacts”

   Emphasised at this step: Build pipeline console.

5. Govern what may leave

   Uploads to her own firm's cloud tenant are inspected against the same data rules, because a contractor keeping notes in her own environment is normal behaviour and the point at which enterprise artefacts leave every control the enterprise operates.

   • Request: Session and data controls to Contractor's cloud storage, “Inspected uploads to her own tenant”

   Emphasised at this step: Contractor's cloud storage.

6. Let the end date do the revoking

   The grant carries a hard expiry, so on day forty-three the same session stops authorising without anybody filing a removal ticket, and the events that prove when it stopped are already with security operations for the access review.

   • Context: Policy engine to Access broker, “Grant expires at the end of day 42”
   • Telemetry: Access broker to Security operations, “Session and grant events”
   • Telemetry: Policy engine to Security operations, “Every verdict and the expiry behind it”
   • Telemetry: Session and data controls to Security operations, “Inspection and data-handling events”

   Emphasised at this step: Security operations.

Attempts shown, and where each one stops

• Attacker holding her credentials attempts:

  • Attack: Attacker holding her credentials to Remote-access VPN, “Stolen credentials used on a VPN account”
  • Attack: Attacker holding her credentials to Access broker, “The same credentials tried at the broker”
  • Terminated here by Access broker — “Refused: expired grant, unknown device”. The line stops short and takes a bar, not an arrowhead.

• Remote-access VPN attempts:

  • Attack: Remote-access VPN to Finance system, “Lateral movement to whatever routing reaches”

  Nothing in this diagram terminates these attempts. That is deliberate rather than an omission: no control shown here can prevent them, so every one of these lines carries an arrowhead and none carries a bar.

• Contractor's laptop attempts:

  • Attack: Contractor's laptop to Contractor's cloud storage, “Artefacts copied out of the session”
  • Terminated here by Session and data controls — “Copy out of the isolated session refused”. The line stops short and takes a bar, not an arrowhead.

Also shown, outside the walkthrough

• Request: Contractor's laptop to Remote-access VPN, “The easy answer, an account and a route”

Annotations

1. What the fast answer would have granted

   Relationship — Request: Contractor's laptop to Remote-access VPN, “The easy answer, an account and a route”

   This is the path of least resistance, drawn so its cost is visible. It answers a routing question, and routing is transitive: once a session is placed on the network, reachability follows topology rather than the engagement scope. Carrying traffic is what the service is for; deciding whether the traffic should exist is a different job.

2. Why nothing terminates this line

   Relationship — Attack: Remote-access VPN to Finance system, “Lateral movement to whatever routing reaches”

   No control sits between the network route and a system the contractor was never scoped for, which is what makes this the natural attack in a network-shaped grant. The absence of a terminator here is the finding, not an omission in the drawing.

3. The same credentials, two months later

   Relationship — Blocked: Attacker holding her credentials stopped at Access broker, “Refused: expired grant, unknown device”

   The credentials are genuine, so authentication is not what ends this attempt. It ends because the grant behind them has an end date that has passed and the device presenting them is unknown. A grant with no expiry would have left this line reaching its destination.

4. Expiry ends authorisation, not existence

   Relationship — Context: Policy engine to Access broker, “Grant expires at the end of day 42”

   The access stops working because a date passed rather than because somebody remembered. That inverts the default in the right direction, and it is not cleanup: the guest identity, its group memberships and whatever records the console created all survive until a lifecycle job removes them.

5. The refusal that will be argued about

   Relationship — Blocked: Contractor's laptop stopped at Session and data controls, “Copy out of the isolated session refused”

   This attempt ends at the control rather than at the laptop, and it is the one the contractor will raise. Keeping the artefacts inside the session is the compensating measure for a device nobody can measure, and it costs her the tooling she normally works with.

6. What the boundary badge is claiming

   Boundary “Contractor's own environment” (third party)

   The enclosure states that this environment is operated by somebody else, under their patching, their monitoring and their contract. That is not an accusation and it does not stop work happening there. It does mean every posture claim crossing this boundary is an assertion, and assertions are recorded rather than believed.

7. The unit of access is an application

   Component “Access broker”

   A grant here names a console, not a subnet, so the blast radius of the engagement is the thing the engagement was for. The price is an inventory somebody has to maintain and a broker on the critical path of a contractor billing by the hour.

8. One authoritative record, or none

   Component “Engagement record”

   A ticket records that a request was fulfilled; it does not record who remains accountable afterwards. If the ticket, the directory and the supplier contract each hold a version of the scope and the end date, none of them is authoritative and the access review has nothing to check against.