A Valid Login Should Not Authorise Every Important Action

Most business systems make a simple assumption once somebody has signed in: if the session is valid and the account has permission, the next action is allowed. That is convenient for routine work. It becomes dangerous when the next click creates a new access token, changes a payment destination, edits an integration or gives an automated process a wider route through company data.

GitHub has introduced a useful control for that gap. Its new proof-of-presence feature can require an enterprise user to authenticate again before carrying out selected high-impact actions. The feature is currently a public preview for managed-user enterprises using Microsoft Entra ID for single sign-on, so it is not a general control available to every GitHub customer. The design principle, however, applies far beyond GitHub.

A person or automation may have legitimate everyday access without having standing authority for every sensitive action. Reliable systems recognise that difference at the moment it matters.

What GitHub Has Changed

GitHub already uses a mechanism called sudo mode to ask users to confirm their identity before sensitive account activity. Proof of presence extends that idea for enterprise environments. An organisation can send a user back to its identity provider when they attempt a high-impact action and require a fresh sign-in, multi-factor authentication or another policy check such as device compliance.

The initial examples include creating a token, editing webhooks, changing organisation security settings and viewing recovery codes. GitHub says support for checks before pull request merges is coming later. After a successful challenge, the proof remains valid in that browser session for two hours, rather than interrupting the user before every individual change.

This is a response to a practical weakness in normal access control. A valid session cookie or long-lived token proves that the system recognises a credential. It does not prove that the authorised person is still present, that their device has not been compromised or that an agent using their session has stayed within the job it was given. GitHub explicitly links the release to stolen sessions and tokens seen in recent software supply-chain attacks.

The important distinction is between identity, permission and current intent. A user can be correctly identified and broadly permitted while a particular action still deserves a new check.

Everyday Access and Exceptional Authority

The same distinction appears in ordinary business software. A finance administrator needs access to supplier records throughout the day. That does not mean an open browser session should be enough to replace bank details and release the next payment. A customer-service integration may need to read orders and prepare refunds. That does not mean it should issue an unusually large refund without somebody confirming the case.

Many automation projects treat permission as a setup task. The system receives an account, API key or connection to another application, then keeps that access until somebody remembers to review it. That approach is easy to build because every run follows the same technical route. It also means the automation's authority can quietly exceed its purpose.

A stronger design separates the frequent, low-risk steps from the small number of consequential ones. Reading an approved mailbox, matching an invoice to a purchase order and preparing an update may happen automatically. Changing a payee, sending money, deleting a record or expanding access should trigger a fresh decision. The check belongs close to the action, with enough context for the approver to understand what will happen.

Following a Supplier Change From Email to Payment

Consider a growing maintenance business that receives supplier invoices by email. An automation monitors the accounts inbox, extracts the supplier name, invoice number, amount and bank details, then matches the invoice against purchase orders in the finance system. Clean matches are prepared for the weekly payment run, while exceptions are sent to the finance manager.

One morning, an email arrives that appears to come from a regular parts supplier. It says the supplier has changed banks and asks the business to use a new account. The message includes a convincing invoice and the automation extracts the new details correctly. Nothing has technically failed. The dangerous outcome comes from allowing accurate extraction to become authority to alter a trusted payment record.

In a controlled route, the automation detects that the sort code and account number differ from the supplier master record. It continues the safe work by capturing the invoice, linking the purchase order and recording the discrepancy, but it cannot update the payee. The finance system creates a high-impact change request showing the old details, proposed details, invoice, source email and supplier contact already held on file.

The finance manager verifies the change using a known telephone number rather than the contact details in the new message. A second authorised person then signs in again with multi-factor authentication and approves the amended record. The approval log stores the people involved, the evidence reviewed, the exact fields changed and the time. Only then can the invoice enter the payment run.

That end-to-end design does more than add an approval button. It stops a compromised email account, stolen browser session or over-permissioned AI tool from completing the whole chain alone. Routine invoices still move quickly, while an unusual event receives proportionate attention. If the check cannot be completed, the invoice remains visible as an exception instead of disappearing into an inbox or being paid on trust.

Where Fresh Approval Can Still Fail

An extra authentication screen is useful, but it cannot rescue a badly designed process by itself. If an approver sees only a generic message such as "confirm change", they may authenticate without understanding the consequence. The screen should show the action, affected record, old and new values, source of the request and any risk signal that caused the interruption.

Approval fatigue creates another weakness. If every small edit demands multi-factor authentication, people will rush through prompts or find routes around the control. High-impact actions need a narrow definition based on business harm, not a blanket rule applied to anything an administrator can do. The two-hour window in GitHub's design also illustrates a trade-off: fewer interruptions make work easier, but the organisation must decide whether the freshness period suits the sensitivity of its own actions.

Automation introduces a further complication because some jobs run without a person at the keyboard. A background process cannot prove human presence in the same way. It needs a deliberately limited service identity, short-lived credentials where possible and a queue that pauses when human authority is required. Reusing one employee's broad account for unattended work removes the very separation the control is meant to create.

Recovery routes matter too. If the usual approver is away or the identity provider is unavailable, staff need a documented fallback with equivalent evidence and oversight. An emergency bypass that is easier than the normal route will eventually become the normal route.

Put the Check at the Point of Consequence

GitHub's release is aimed at a particular enterprise setup, but it exposes a question that belongs in every connected workflow: which actions should a valid session be able to complete without fresh human intent?

Start with the consequences rather than the software menu. Identify actions that move money, expose sensitive data, change who has access, alter an integration, publish externally or create a commitment that is difficult to reverse. For each one, decide what evidence the approver needs, how recent the authentication must be, what the system records and what happens when approval is withheld.

This need not turn every process into a chain of permission requests. Good automation removes attention from routine work and concentrates it where judgement changes the outcome. A clear boundary lets the system complete the safe majority while making exceptional authority visible.

Birdcage Tech designs bespoke software, integrations and automations around the complete operating route, including the moments where access should stop and accountable approval should begin. If an important process currently relies on a shared login, a long-lived token or somebody noticing an unusual change in time, we can help turn it into a faster and more controlled system.