# TTL Should Be a First-Class Security Control for AI Agents Most agent platforms treat time-to-live (TTL) as an operational knob. "How long should this run before we clean it up for cost reasons?" TTL is a security control. Treating it as anything less is a mistake. ## The window of opportunity Every credential, every tool access, and every bit of context you give an agent represents a potential window for abuse. The longer that window stays open, the more damage a compromised or misbehaving agent can do. A 6-hour agent with write access to a repository and a deployment key can do a lot more harm than a 30-minute agent with the same access. This is not theoretical. Attackers and automated abuse will use whatever duration you give them. Declaring a short TTL is not just "cleaning up resources." It is deliberately closing the window. ## Why defaulting to long-lived is the industry norm Frameworks often optimize for "set it and forget it" agents. A background worker that watches a queue or a Slack channel feels powerful. It can react to events whenever they happen. The cost of that power is that the agent (and everything it can reach) is now a persistent target. Many teams accept this tradeoff because they have not yet felt the pain of a compromised long-running agent. They will. ## TTL as part of the contract In a recipe, TTL is not a deployment setting. It is part of the definition of the agent: ```yaml name: sdr-agent ttl: 1h ... ``` This means: "This particular capability is only allowed to exist for one hour per activation." When you change the TTL, you are changing the security posture of that agent. That change should be reviewed with the same seriousness as changing which tools or secrets it receives. ## The extend mechanism as a safety valve A useful pattern is to give the agent (or the operator) a way to request an extension before the TTL expires, rather than making the initial TTL very long "just in case." Five minutes before timeout, the control interface can ask: "This agent is about to sleep. Extend by another hour?" This keeps the default lifetime short while still supporting legitimately long-running work. The extension is an explicit, auditable action rather than the default state. ## Interaction with snapshots TTL and state snapshots work together. A short TTL forces the agent to produce useful output or persisted state within its window. It cannot slowly accumulate work across days inside one long-lived process while holding broad access the whole time. When the agent sleeps, the state is saved. The next activation is a new, time-bounded execution with fresh credentials (if the recipe declares them). ## Operational vs security TTLs You will sometimes hear two different numbers: - "This agent should finish its work within 45 minutes on average." - "We want to allow it to run for up to 4 hours in case something is slow." The second number is the security boundary. That is the one that should be declared in the recipe and enforced by the runtime. The first is a performance target. Conflating the two leads to very long TTLs "because sometimes it takes a while." ## What good TTL discipline looks like Teams that treat TTL seriously tend to have: - Most agents with TTLs measured in minutes or low hours, not days. - Clear justification in the recipe or accompanying docs for why a particular agent needs a longer window. - Monitoring and alerting on agents that frequently hit their TTL (this is often a sign the mission scope is too broad). - Extension flows that require explicit action rather than silent background continuation. They also stop treating "the agent" as a single entity that should stay up. They think in terms of missions that start, do work, and end. ## The default should be suspicious The industry default for new agent projects is often "leave it running." The safer default is "this should be done and gone as quickly as possible." You can always grant more time for a specific mission when you have evidence that it is necessary. Starting from a position of short lifetimes and explicit extensions is much harder to regret later. TTL is one of the cheapest and most effective security controls available for agents. Use it like one.