Contractor & Temporary Access with Expiry

The problem this kills

A contractor starts on Monday. Someone emails IT "please give them access to the file share and a badge," IT does it, and everyone moves on. The project wraps in March. Nobody tells IT. It's now August and that contractor still has a working login, a building badge, and a seat in three systems they haven't touched in five months. You only find out during an audit, or worse, after something goes wrong.

This is one of the most common and most dangerous gaps in any organization: external access that outlives the engagement. The contractor leaves, the vendor's project ends, the temp's assignment finishes - but the access just sits there, open-ended, because granting access has an obvious trigger (someone starts) and revoking it has no trigger at all (nobody remembers). Spreadsheets that try to track it go stale within a month. The result is a pile of orphaned accounts and live badges nobody owns, each one a way in for someone who shouldn't have it.

This tool closes the gap by making it structurally impossible to grant open-ended external access. Every grant requires an end date. The app reminds you before and at expiry, auto-flags the grant for revoke when the clock runs out, and makes a human confirm the access is actually gone - so external access ends when the engagement ends, on purpose, every time.

What you'll build

A small internal web app, just for your team, that:

• Lets you request temporary access for a contractor, vendor, or temp - choosing the access types (systems, building, or both) and setting a required end date (no open-ended grants, ever).
• Routes each request to the internal sponsor (who vouches for the engagement) and the access owner (who owns that system or door) for two approvals before anything is provisioned.
• Issues a grant task to the right owner once approved - a clear "provision this, expiring on this date" instruction.
• Sends reminders before and at expiry so nothing lapses quietly, and auto-flags every grant for revoke the moment it expires.
• Runs a clean revoke flow: the access owner removes access, the sponsor confirms it's actually gone, and the grant is closed.
• Requires re-approval for any extension - you can't quietly stretch a grant; a new end date needs fresh sign-off.
• Dedupes so the same contractor can't hold two active grants for the same access at once.
• Exports grant tasks and revoke tasks as CSV so the tool works today even with no connection to your identity or badge system.

What's inside the Implementation Plan

The plan is a single markdown file you paste into Claude Code (a free AI coding agent). It walks the agent through building the whole tool, step by step, each step ending with a ready-to-paste prompt.

The most important part: the plan opens by interviewing you about your business. Before it writes a single line, the agent asks how temporary access gets requested and revoked today, which systems and doors are in scope and who owns each, the exact naming and codes you use for access types and contractors, your typical and peak volumes, your two-gate approval rules, your reminder timing, and your messiest edge cases (an engagement that ends early, a contractor who needs a second system mid-project, an extension request the day before expiry). It reads a short tailored spec back to you, you confirm it, and only then does it build - so you get a tool shaped to how your access actually works, not a generic template you have to fight.

Inside you'll find:

• The discovery interview and how the agent turns your answers into the data model, the access catalog, and the expiry rules.
• The full build: database, login, the access-type and sponsor catalog, the request form with a mandatory end date and duplicate guard, the two-gate approval, the grant-task issuance, the expiry reminders, the auto-flag-at-expiry, the revoke confirmation, and the extension re-approval.
• The hard rules - no open-ended access, every extension re-approved, nothing provisioned without sponsor and owner sign-off - enforced in code.
• Verification steps so you can prove it works, and the CSV-export fallback so it's fully usable even before you connect it to your identity or badge system.

The governance it includes (this is the point)

This isn't a toy. The plan builds in the controls an access process actually needs:

• Login so only your team can see or touch anything.
• Row-level security so people only see their own organization's data, and owners only see the access types they're responsible for.
• A complete audit trail - every request, approval, grant task, reminder, expiry flag, revoke, and extension is logged with who and when.
• A hard human-in-the-loop gate - the app drafts and routes, but the internal sponsor and the access owner must both approve before any access is provisioned or extended; nothing is granted automatically.
• A no-open-ended rule enforced in code - every grant must carry an end date, and extensions require fresh approval.
• Duplicate guards so the same contractor can't end up with two active grants for the same access.

Who it's for

IT security, vendor managers, facilities and physical-security teams, and project managers - anyone responsible for letting outside people in and, just as importantly, making sure they're out again when the work is done. If you bring in contractors, vendors, auditors, seasonal temps, or partner staff and you've ever found a live account or badge that should have been killed months ago, this is for you. You don't need to write code. You need your list of access types and owners, your sponsors, and an afternoon.

You've got this - paste the first prompt and let the agent interview you.