Time Is a Security Boundary

We recently had a security incident. As much as it is uncomfortable, it is part of the life of a modern organisation.

One of the first questions was whether our own AI systems had created the opening. It was a reasonable question. Rapidly evolving practices, loosely managed API keys, exposed environment variables, vibe coding with LLMs, and dubious agent harnesses all create new opportunities to leak credentials or introduce vulnerabilities.

AI also changes the security landscape more broadly. Models can discover vulnerabilities, automate reconnaissance, and chain exploits together at a speed that was previously difficult to achieve.

We have seen the defensive side of that capability too. We use AI extensively to inspect and harden software, and we have built security harnesses that found critical bugs in code that had been running for decades.

SecOps is becoming faster and more dynamic.

But after answering the original question somewhat defensively, I started wondering how much the fundamentals had really changed.

I think that mostly, they have not.

The same rules still apply: separate concerns, grant minimal permissions, isolate systems, create observable boundaries, and assume that individual components will eventually fail.

One underrated strategy may become even more important in an AI-driven security environment: imposing speed limits.

In other words, using time as a security boundary.

Automated attacks thrive on speed. An AI system can probe a weakness, adjust its approach, escalate privileges, and move laterally before a human operator has understood the first alert.

Its advantage comes partly from chaining many small actions together without interruption. The obvious defensive response is to break the chain.

A new credential does not need immediate access to every environment.

A destructive deployment does not need to execute instantly.

A large transfer does not need to clear the moment it is requested.

A sensitive permission change can remain pending before becoming active.

These deliberate slow points create time for detection, review, and intervention.

They also increase the cost and complexity of automation. The point is not that an automated system is incapable of waiting. It is that delay creates opportunities for the surrounding environment to change. Sessions expire. Credentials rotate. State changes. Assumptions become stale. Defensive systems gain time to inspect, interrupt, or contain the workflow.

A chain that can be completed in seconds may be easy to automate. One that must remain valid and coherent across hours or days is a different problem.

Time is not a security boundary because machines cannot wait. It is a security boundary because delay gives the rest of the system time to react.

This is also a useful way to think about AI guardrails.

Guardrails are often imagined as filters that stop a model from producing certain outputs. In operational systems, they should also include permissions, rate limits, staged execution, sandboxes, approval thresholds, and intentional latency.

Their purpose is not to make failure impossible. It is to stop a fast, local failure from becoming an immediate, systemic one.

AI allows attackers to move faster than before. That makes it even more important to decide where sensible speed limits should exist. The same mechanisms also protect against human error, compromised credentials, and poorly designed automation.

Intentional latency is only useful when something is watching. If a permission change remains pending for an hour, that hour should be used: to inspect the request, compare it with normal behaviour, rotate credentials, or interrupt the workflow.

AI gives attackers greater speed, but it also gives defenders the ability to maintain continuous, agentic vigilance, the digital equivalent of a guard walking the perimeter.

The goal is not to prevent every failure. It is to ensure that a small failure cannot move through the entire system faster than we can see it.