99% of repository access tokens never expire, leaving code wide open

The problem with tokens that never die

Imagine handing out keys to your office and never asking for them back. That developer who left six months ago? Still has one. The contractor who finished in March? Kept theirs. The AI coding agent you set up for a proof of concept? It's still running, with full write access.

That's how most repository access works, according to BlueFlag Security's latest findings. Ninety-nine per cent of repository access tokens never expire ^[1]. Developers get tokens for Git, CI/CD pipelines and package registries, and those tokens carry on working long after the person, contractor or bot has moved on. Most organisations have no systematic way of knowing who still has access to code, deployment pipelines or production secrets.

The same report found that 40% of organisations had granted repository access to AI coding agents, and only 20% of those tokens ever expired ^[1]. When an AI agent writes or reviews code, it does so with whatever permissions it was given at setup. If nobody revokes them, the agent keeps them.

What the rules say

Sweden's Cybersecurity Act, which implements the EU's NIS2 Directive, came into force on 15 January 2026 ^[2]. It covers essential and important entities in 18 sectors, including energy, transport, healthcare, digital infrastructure and public administration. One of its requirements is documented risk management, and that includes access control.

When an incident happens, the law sets deadlines: an early warning within 24 hours, an incident notification within 72 hours, and a final report within a month ^[2]. Those hours start ticking when the organisation became aware of the incident, not when it suits them. If someone asks how an ex-contractor's credentials were used to push a malicious commit three weeks after their contract ended, the clock on that question started the moment someone noticed.

DORA's technical standard on ICT risk management, which has applied since 17 January 2025, requires logs to be protected against tampering, deletion and unauthorised access ^[3]. For a bank, an insurer or a payment institution, that means being able to show supervisors and auditors that access logs haven't been quietly edited after the fact.

Why access logs matter

Logs are like receipts: nobody looks at them until there's a problem. Then they become the only record of what happened. An access log shows who authenticated, when, from where and what they did. If that log can be edited by the same people who appear in it, it's easy to challenge.

The difficulty is proving that a log is the one written on the day, unchanged. Access controls and monitoring are essential, but they don't answer the question a supervisor or an auditor will ask: how do I know this log is the real one?

Sealing access logs as they are written

Here, the thing to seal is the access log itself, in segments. Each time a segment closes—say, every few minutes—a fingerprint is taken and sealed with WitniumChain. The segment stays where it is, in your own systems. What gets sealed is the fingerprint, a short string that changes completely if a single character in the log changes.

Anyone you share the log with can later recalculate the fingerprint and compare it with the sealed one. If they match, the log is exactly what was written at that time. If someone with administrator rights goes back and edits an entry, the fingerprint won't match, and the change shows.

The access log still needs to be kept securely, with proper access controls and monitoring in place. A digital witness doesn't replace any of that. What it does is give you a way to show, later, that the log you're handing to a supervisor or an auditor is the one written on the day.

How it would work

1. Your logging system closes each segment at a set interval and sends a fingerprint to WitniumChain through the REST API, SDK or MCP server.
2. You get a witness ID back, which you store alongside the segment.
3. When someone checks, they recalculate the fingerprint from the log segment and compare it with the sealed one using the witness ID.

Your system sends a fingerprint of the record, not the record itself, to WitniumChain through the REST API, the SDK or the MCP server, and gets a witness ID back. To check, anyone you share the record with calculates the fingerprint again and compares it with the sealed one. The first 2,000 witnesses a month are free.

What it shows is that the log segment hasn't changed since it was sealed. What it doesn't show is that the log is complete, that every access was authorised, or that your access controls were adequate. Those are separate questions, and important ones.

What this means for you

If your organisation writes code, deploys software or uses AI coding agents, ask yourself:

• Do you know which tokens are still active, and who or what holds them?
• Could you show an auditor or a supervisor that your access logs haven't been edited after an incident?
• If an ex-employee or contractor's credentials turned up in a breach, could you prove when their access ended?
• Do the AI agents in your development pipeline still have the permissions they were given months ago?

Tokens that never expire are convenient until they're not. The Cybersecurity Act and DORA both ask for documented access control and trustworthy logs. Sealing log segments as they are written is one way to make those logs hold up when someone asks to see them.

What to watch

The Cybersecurity Act applies from 15 January 2026 in Sweden, with the 24-hour early warning deadline counting from when an organisation becomes aware of an incident ^[2]. DORA's technical standards on ICT risk management have applied since 17 January 2025, including the requirement for logs protected against tampering ^[3].