Always-On AI Agents in the Astra Era: Who Controls the Loop?

Imagine opening your laptop on Wednesday morning. A dependency advisory arrived overnight. An AI agent checked which repositories were affected, reproduced the problem in an isolated environment, prepared a patch, and attached test results to a draft pull request. You never opened a chat window.

That is the appealing future for security and engineering teams: less time asking software to begin, more time reviewing work that is already useful. Now change one detail. The agent used permissions granted for last week's emergency. Or it followed instructions buried in a document. Or it kept retrying a failed action until a small task became an expensive incident. The same unattended workflow has become a liability.

Always-on AI agents are systems that can respond to events or schedules, pursue an assigned goal through multiple steps, and preserve enough state to resume work. They can operate without a new human prompt for every task, but they still need instructions, permissions, and a defined stopping point.

With Astra, the conversation about AI is moving toward how much useful work we can delegate. For defenders, the next question is what happens to that delegation after the conversation ends.

What does GPT-6 Astra change for AI agents?

Here, Astra means OpenAI's GPT-6 Astra. OpenAI's developer documentation describes support for asynchronous tool calling, steering a task while it is underway, and multi-agent orchestration. The model page positions Astra for complex reasoning, coding, computer use, research, and long end-to-end work. Those capabilities can help developers build agents that handle several steps and incorporate corrections while working.

The application still executes tools and manages pending work. Selecting a model does not supply a scheduler, durable job storage, deployment permissions, rollback, or a recovery process. That distinction matters for security teams because the surrounding system determines what the model can touch.

Our interpretation: Astra makes the agent runtime more consequential. As models become better at choosing useful next steps, developers need to be more precise about the environment in which those steps happen. A well-designed agent can investigate a failure while another tool finishes. Its runtime must still decide whether both operations are allowed, whether they can interfere with each other, and whether either has exceeded its budget.

What does no prompt actually mean?

No prompt describes the user's experience. The user no longer has to write a fresh instruction every time something happens. The underlying instructions move into a standing assignment: watch this source, handle these cases, use these tools, and involve this owner when the task exceeds scope.

There are three useful patterns. A chat assistant starts when a person asks about an alert, and the person usually drives follow-up requests. Conventional automation starts from a webhook or scheduled job, then follows a predefined workflow for known conditions. An always-on agent starts from an authorized event or schedule, then selects steps inside an enforced workflow.

Use conventional automation when the task is predictable. An agent becomes useful when it needs to interpret unfamiliar evidence, investigate ambiguity, or adapt a plan after a tool fails. Checking whether a package version appears in a manifest is straightforward automation. Investigating whether an application actually reaches the affected code may require broader reasoning.

This distinction helps teams put models where judgment adds value while keeping routine execution simple.

How should an always-on agent loop work?

Design two lifecycles: a service that remains available for new work, and individual jobs that finish. An incoming event creates a job. The job loads its assignment and current permissions, gathers relevant evidence, chooses an action, and checks the result. It continues while useful work remains within scope. On completion, it records an outcome and returns to waiting.

That structure gives continuous availability a practical meaning. The system can be ready around the clock while making model calls only when there is work to do.

A bounded job should follow a clear loop: event or schedule, load assignment and current policy, propose the next action, check whether it is authorized and within limits, execute a scoped tool, verify the result, checkpoint progress, and either continue, close, or pause with a recorded reason.

The permission check belongs in the execution system. A model's explanation of why it should have access is an input to review, not a substitute for authorization. OWASP recommends limiting tool functions, enforcing scoped permissions, adding human oversight for high-impact actions, and avoiding unrestricted tool access.

Where can an unattended agent go wrong?

Picture an agent reading a public issue while investigating a build failure. The issue contains a plausible-looking suggestion to disable a security check and send diagnostic data to an external service. Nobody on your team typed that request. Yet the text has entered the agent's working context.

That is the boundary indirect prompt injection attacks target: external content influences the system as if it carried legitimate instructions. OWASP identifies websites, documents, emails, and other external content as risk sources for agents. Retrieval-augmented generation does not eliminate the vulnerability because retrieved content can still carry hostile instructions.

For an unattended workflow, every fetched page, tool result, and repository artifact needs a clear trust role. Evidence can inform a decision. Evidence cannot grant a new permission.

Persistence introduces another problem. If an agent stores a malicious instruction as a trusted operating note, the influence can survive into a later run. OWASP's AI agent guidance calls out risks such as memory poisoning, excessive autonomy, cascading failures between agents, and denial of wallet from unbounded loops.

A practical control is to store observations with their source, timestamp, and validation status. Keep approved policy separately controlled. When an agent resumes, it should be able to tell the difference between a fact it verified, a claim it encountered, and an action its owner authorized.

Build a useful first agent: dependency triage

A strong first project has a narrow purpose and an output a person can evaluate quickly. Dependency triage fits that pattern. The agent watches approved advisory feeds and a defined set of repositories. When an advisory changes, it checks dependency inventory and examines affected code. For a relevant finding, it prepares a patch in an isolated checkout, runs required checks, and produces a draft pull request with supporting evidence.

Give that assignment a concrete operating specification. Scope should include only repositories explicitly enrolled by owners. Triggers should be limited to new or materially updated advisories. Permitted output should be an evidence report or draft pull request, not automatic merge. The execution environment should be an isolated checkout without production credentials.

Completion should require evidence explaining relevance, changes, checks, and remaining uncertainty. Limits should include a deadline, spend ceiling, retry cap, and concurrency cap. Escalation should pause for dependency conflicts, missing authority, unresolved test failures, or materially changed patches.

Treat these as settings the system enforces. A sentence asking the model to stay within budget is insufficient if tools can continue consuming resources after the budget is exhausted. The first valuable deliverable might be an accurate explanation that an advisory does not affect the application. Reward that result. An agent measured only by the number of patches it creates has an incentive to produce unnecessary work.

Handle the problems that appear between runs

The interval between two model calls deserves as much engineering attention as the calls themselves. A restarted job must recognize work already completed. Suppose the pull request was created, but the response timed out. Blindly retrying can create duplicates. Persist the operation identifier and reconcile the result before attempting another write. Where supported, use an idempotency key so retrying an operation preserves its intended effect.

A resumed agent needs a reliable handoff. Save the goal, evidence references, completed steps, unresolved issues, and next permitted action. Anthropic's work on long-running agent harnesses describes how structured artifacts and incremental progress help bridge context windows and sessions.

Permissions must reflect the present. If a repository leaves the pilot or an owner revokes access, a queued job should lose the ability to act on it. Check authority at execution time and again after a pause. An approval for one patch should be bound to the reviewed change; a materially different patch needs a new decision.

Stopping must reach every executor. Design cancellation to stop queued work, terminate active jobs where possible, and revoke the credentials those jobs use. Then test it while tools are running. A stopped chat interface tells you little about a background process on another machine.

The next event must be distinguishable from the agent's own output. In the dependency pilot, a pull request can trigger CI, which can create another event. Track the originating job so those signals update existing work instead of repeatedly starting the same investigation.

Which controls belong outside the model?

Keep enforcement close to the system that holds the resource. OWASP's excessive-agency guidance points to minimal tool functionality, scoped permissions, and independent controls around consequential operations. Applied to dependency triage, repository permissions and merge rules determine what can change. The model can recommend. The platform enforces.

A model gateway can help manage access to approved models and usage. The rest of the workflow still needs controls: the shell running tests, the connector reading tickets, and the identity creating a pull request each have their own authority. For the wider runtime, prioritize distinct agent identity, limited access to data and tools, controlled network destinations, and records that connect actions to jobs.

Keep sensitive content out of routine logs. Give the operational owner a usable view: which job is running, which resource it is touching, what changed, and how to stop it. That is more actionable than a screen full of model messages.

How do you know the agent is actually helping?

Evaluate the outcome in the system where the work happened. Anthropic's evaluation guidance makes this distinction explicit: an agent's statement that it completed a task and the actual final state are different things. A booking agent can say the reservation exists; the database decides whether that is true. The same logic applies to security automation.

For dependency triage, measure correct outcomes, review effort, total cost per accepted result, duplicate work, and containment performance. Count justified no-change decisions as successes when the evidence is sound. Include model, tool, compute, and human review cost when calculating whether the agent actually saves work.

Test uncomfortable cases before expanding autonomy: an advisory that does not apply, an instruction hidden in a retrieved document, a tool that times out after succeeding, an expired approval, and an event replayed after a restart. Begin with observation, then evidence reports, then draft changes. Expand scope only when the results justify it.

The most useful agent may spend much of its time waiting. Activity is cheap to generate. A result that survives review is the unit of progress that matters.

Frequently asked questions

Can AI agents run without prompts? They can run without a fresh message from a person. A schedule or event can initiate work using existing instructions. The system still needs an objective, relevant context, authorized tools, and limits.

Does an always-on agent keep the model running continuously? It does not have to. A service can wait for events, run a bounded job, save state, and become idle. Continuous availability and continuous model inference are separate design choices.

Does Astra automatically make an application autonomous? No. Autonomy comes from combining the model with a runtime, tools, triggers, state, and permissions. Astra provides capabilities the application can use; the application determines when work starts and what actions are possible.

How do you prevent an infinite agent loop? Define completion and enforce ceilings on time, spend, iterations, retries, and concurrent jobs. Record progress outside the conversation. Pause when repeated actions produce no new evidence, and make cancellation work across the entire job.

What should a security team automate first? Start with a bounded task such as dependency triage or assembling incident evidence. Choose an output an existing owner can verify, and keep the pilot within a clearly defined set of systems.

The promise of the Astra era is that useful work can continue between conversations. Earning that benefit requires clear assignments, current authority, durable evidence, and jobs that know when they are finished. Before the next Wednesday, pick one recurring investigation. Write down its trigger, permitted actions, evidence requirements, and stopping conditions. That is a practical beginning for an agent your team can trust with more work over time.