Security playbook · AI Employee: Sig

Just-In-Time (JIT) Access

Elevated access is time-boxed and audited; zero standing prod access

Install this playbookBack to marketplace
The problem

Standing privileged access is the single largest attack surface most companies never address. Everyone knows JIT is best-practice. Everyone knows implementing it means friction. The compromise ends up being either "nobody has prod access" (blocks operations) or "everyone has prod access" (blocks audit). JIT should be the default, but only if the request-to-grant flow is measured in seconds, not tickets.

At a glance
Trigger
Chat with approval
Approvals
Manager + security approval; step-up MFA on requester
What it does
Writes to your systems
Systems
Okta · AWS IAM · GCP IAM · Terraform Cloud
How it feels in production

An hour-by-hour walkthrough.

3:47am. Priya is on-call for the payments team. PagerDuty pages her: elevated latency on the payments box. She needs sudo on prod-payments-1 to run diagnostics. 3:48am. Priya DMs Sig in Slack: "grant me sudo on prod-payments-1 for 30 minutes, incident #INC-4211." Sig reads the request, checks Priya's team (payments — matches the resource), her on-call status (yes, currently on-call), and the incident ID (real, active P1). Routes an approval to the on-call security manager (or their delegate at 3am) with the context bundled. 3:49am. On-call security tap-approves. Sig writes an ephemeral IAM grant with valid_until = now + 30min. Priya's session activates immediately. She runs the diagnostic, finds the culprit, resolves the incident. 4:23am the grant expires; the revoke fires; Priya's sudo goes away. Full audit trail: who requested, what justification, who approved, when the grant activated, what commands were run (if command logging is on), when the revoke fired. Every write ties back to the incident ID. Zero standing access. Zero friction. When someone requests JIT without a valid justification, or on a resource they can't attribute to their team, or repeatedly on the same day, the request escalates to security lead — the pattern itself is signal.
How it works

Step by step.

  1. 01

    Collect target + justification + duration

    Request in Slack / Teams: target role or resource, business justification (incident ID, ticket, project), duration (max 8 hours by default; 30 min for high-risk resources).

    Slack · Teams
  2. 02

    Route to owner + security

    Approval card sent to the resource's owning team lead (context: requester's team, on-call status, related incident). Security lead added as second approver on high-risk resources. Step-up MFA required on both approvers.

    Slack · Approval Policies
  3. 03

    Grant scoped role on approval

    IAM write with the minimum scope required: single-resource role, not broad admin. Writes an edge to Context Graph with valid_until set. Grant activates immediately.

    Okta · AWS IAM · GCP IAM · Terraform Cloud
  4. 04

    Set auto-expiry

    Scheduled task watches the valid_until edge. On expiry, the revoke fires: IAM permission removed, session invalidated, edge marked expired in Context Graph.

    Context Graph · Scheduler
  5. 05

    Post grant + revoke to audit

    Both events written to audit_events with actor, target, justification, approver, timestamp. Weekly digest to security lead with all elevations, their justifications, and their durations.

    Audit log · Slack
Systems and wiring

What you connect to make this run.

Okta · Microsoft Entra ID

write

Service account with role-assign + time-scoped-grant scopes. Grants scoped to specific groups, not broad admin.

AWS IAM · GCP IAM · Azure AD

write

IAM role-assumption via time-boxed session tokens. Sig assumes a security-owned role and delegates a scoped session to the requester with the requested TTL.

Terraform Cloud

write

For IaC changes, JIT grants the requester temporary workspace access. Approval chain includes code review before apply.

Context Graph

read+write

Read the requester's team, on-call status, incident context. Write the grant edge with valid_until; scheduler watches for expiry.

PagerDuty · Incident.io

read

Verify the incident ID cited in the justification exists and is active. Prevents fake-incident abuse.

What changes

Before and after, honestly.

Time from request to grant
Before
20-90 minutes across manual ticket + approval + IAM change
After
Under 2 minutes for verified requests
Standing prod-access accounts
Before
50-200 (grew organically over years)
After
Zero for scoped roles; only break-glass accounts (2-3) remain
Time-to-revoke on expiry
Before
Never (JIT with manual revoke = permanent grants in practice)
After
Automatic within seconds of valid_until
SOC 2 access-review effort
Before
Days of spreadsheet reconciliation quarterly
After
Every grant + revoke already in audit; report auto-generates
Related

Playbooks that pair with this one.

Security

User Access Reviews (UAR)

The quarterly review that would run against a much shorter list once JIT is in place.

Security

Cloud IAM Reviews

The scheduled cleanup that catches roles left unused > 90 days.

HR

Employee Offboarding

Offboarding relies on JIT to have removed standing grants — a much smaller cleanup.

Security

Secret & API Key Rotation

The related pattern for machine credentials.

Frequently asked

Answers about this playbook.

How is this different from Sailpoint or CyberArk?

Sailpoint / CyberArk are enterprise IGA / PAM platforms with heavy configuration and quarterly cadences. Sig runs on top as the daily-driver: quick JIT in Slack, evidence-in-Slack auto-approvals for common patterns, real-time revocation. Coexistence common — Sig for daily; IGA for compliance system of record.

What if the on-call approver is asleep and it's a P1?

Approval Policies support escalation chains with configurable timeouts. On-call security is primary; if they don't respond in 5 minutes on a P1 request, escalation to their delegate; then to security lead. Break-glass path documented for the rare case where nobody is available — writes a mandatory security review trigger for the next business day.

Can we skip approval for common patterns?

Yes but carefully. Sig supports policy rules like "on-call engineer + active incident ID + resource matches team = auto-approve up to 30 minutes." Configurable per team; every auto-approval still writes to audit with the rule that authorised it.

What about read-only access requests?

Same flow with lighter approval. Read on prod-payments-log for debugging can auto-approve for on-call team members; write requires human approval.

How do you prevent 'JIT fatigue' — requesting the same access daily?

Sig detects the pattern (3+ requests for same resource in a week) and surfaces it to the requester's manager: "is this a real recurring need? consider a scheduled recurring grant or a role change instead of daily JIT." Doesn't block; nudges toward the right fix.

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.

Book a demoMore Security playbooks