Access automation shouldn't require building and maintaining infrastructure

Write access logic as code that runs inside Opal -- no infrastructure required

An engineer joins the on-call rotation and immediately needs Datadog access to monitor production. In the old world, that's a ticket, an approval queue, and potential delays during an incident window. With OpalScript, the policy verifies group membership and request duration in real time — approving instantly when both conditions are met, and routing to manual review when they aren't. No webhook. No external service. No waiting.

John Clark is not a member of On-call Engineering. The moment his request hits Opal, OpalScript fires — calls accesslib.check_access() against the allowed groups list, gets back false, and denies the request before a single reviewer is notified to act. No queue, no delay, no ambiguity.

This time John Clark is a member of On-call Engineering and requests just one hour of access. accesslib.check_access() returns true, the duration check passes, and OpalScript approves the request instantly — no reviewer queue, no wait, no incident delay. The Datadog access propagates immediately.

John Clark is a member of On-call Engineering — but this time he requests a full day. Group membership passes, but the duration exceeds the 4-hour threshold. OpalScript can't auto-approve, so it adds a comment explaining exactly why and fires notificationslib.notify_owner() to alert the manager. The request sits in Review — waiting for a human to take it from here.

A production incident just triggered. Your on-call engineer needs AdministratorAccess to the Prod AWS Account — right now, not after a 30-minute approval chain. Breakglass access exists for exactly this moment. OpalScript reads the custom fields on the request, verifies breakglass authorization via accesslib, confirms a ticket is attached, and checks the duration. If everything aligns, access is granted in seconds. If anything doesn't, the manager is already notified before they check the queue.

The EKS cluster is down and John Clark needs AdministratorAccess immediately. He sets the breakglass flag and submits — but forgets to attach a ticket number. OpalScript sees the breakglass flag, confirms he's in the authorized group, then checks for a ticket. There isn't one. Request denied before it reaches any reviewer. No ticket, no access — even in a breakglass scenario.

When breakglass is invoked with a valid ticket and the duration is 60 minutes or less, OpalScript instantly approves the request — no human reviewer required. John Clark's emergency EKS access is provisioned in seconds, with ticket NETOPS-15725 recorded in the audit trail.

When breakglass is False — or the duration exceeds 60 minutes — OpalScript escalates to human review rather than making the call itself. Here, John Clark requested 8 hours of non-breakglass access. The script comments its reasoning, steps back, and leaves the decision to the reviewer.

Not all GitHub roles carry the same risk. Admin and Write access can alter code and settings — they warrant a human review. Maintain, Triage, and Read are lower-privilege roles that can be safely auto-approved. This script enforces that distinction automatically, every time.

John Clark requests Write access to infra-as-code-platform for a day — citing a disaster recovery deployment. Write is an elevated role. OpalScript flags it for human review, comments its reasoning, and notifies the owner group. Matt Heffler now has the full context to approve or deny.

John Clark requests Read access to infra-as-code-platform to evaluate what changes are needed — a low-risk, read-only operation. OpalScript recognizes the role, approves instantly, and propagates access in seconds. Matt Heffler is notified but never needs to act.

The first gate in a three-script chain. It classifies the request by risk and duration — auto-approving low and medium-risk requests within one day, and passing everything else up the chain. Permanent access is blocked hard at this tier and every tier that follows.

Picks up where Tier 1 left off. It approves low-risk requests outright and handles the medium-risk, longer-duration cases — flagging anything between 1 day and 1 month for manager review. High-risk roles are passed straight to Tier 3.

Handles everything the first two tiers couldn't resolve. High-risk admin roles always require Director or VP sign-off. Medium-risk access beyond one month is evaluated against a one-year ceiling — requests that exceed it are denied outright. No exceptions, no workarounds.

John Clark requests 7 days of Snowflake PUBLIC access. PUBLIC is LOW_RISK — Tier 1 classifies and passes the chain signal, Tier 2 auto-approves low-risk outright, and Tier 3 does the same. All three OpalScripts approve in sequence. No manager, no director, no reviewer queue — the entire three-tier chain resolves automatically.

John Clark requests 7 days of Snowflake CUSTOMER_SUPPORT access. CUSTOMER_SUPPORT is MEDIUM_RISK — Tier 1 evaluates the duration against the 1-day auto-approve threshold, finds it exceeded, and silently escalates to Tier 2. Tier 2 comments "Manager Approval Required" and queues Adrian Pasqualini for manual sign-off. Tier 3 is notified and armed, but dormant until Tier 2 resolves.

John Clark requests 1 month of Snowflake ACCOUNTADMIN access. ACCOUNTADMIN is HIGH_RISK — no duration shortcut applies. Tier 1 silently escalates to Tier 2, which also escalates and comments "Director/VP Approval Required." Tier 3 queues Dean Walker for manual sign-off. Both Tier 1 and Tier 2 OpalScripts approve in sequence; Tier 3 holds the chain for a Director or VP to decide.

No single person should be able to both write code and deploy it. This script runs on every request for the data-pipeline-analytics GitHub repo — if the requester already holds the EKSClusterAdmin deployment role, write/admin access is blocked on the spot. Script 2 (slide 19) covers the other side.

This script runs on every request for the Prod AWS Account IAM Role — EKSClusterAdmin. It checks whether the requester already holds GitHub write or admin access to the repo — if they do, deployment access is denied, closing the other side of the SoD pair established in Script 1 (slide 18).

John Clark holds no GitHub write or admin access to data-pipeline-analytics. OpalScript checks accesslib.check_access() for both push and admin — gets false for both — and approves EKSClusterAdmin immediately. No conflict, no violation, no delay.

John Clark already holds EKSClusterAdmin. When he requests write access to data-pipeline-analytics, OpalScript checks his existing access — finds the conflict — and denies before any reviewer sees the request. The security team is notified in real time.

Same user, same EKS access — but requesting read-only access to data-pipeline-analytics. OpalScript only checks for push and admin rights. Neither exists for read, so the script approves cleanly. Read access doesn't create a deployment conflict.

OpalScript's architecture ensures your access policies are reliable and secure

Extending OpalScript to more Opal lifecycle events