You Tested It as One Role. It Runs as All of Them.

Snowflake put scheduled, unattended AI agents into public preview on August 21.

You write a prompt, it becomes a recurring job, and it runs in a managed sandbox on a schedule whether your terminal is open or not. That is a useful feature and I expect people will get real value out of it.

Now read the sentence in the documentation that nobody is quoting.

Each run executes as the user who created the automation, using that user's default role and default secondary roles. Not the role that was active when the automation was created.

You Tested It as One Role

Think about how you would actually build one of these.

You are a careful engineer. You switch into a narrowly scoped role, one with read access to exactly the tables the job needs and nothing else. You write the prompt. You watch it run. It does the right thing, touches only what it should, and you schedule it.

Tomorrow morning it runs again as your default role.

Which, if you are the person building automations in a data platform, is probably not the narrow one. It is the role you use for everything else, with the grants you accumulated over three years of being useful to people.

The thing you tested and the thing that runs are two different identities. Nothing failed. No permission was bypassed. The system did exactly what its documentation says it does, and the gap opened anyway.

It Is Already On

Here is the second sentence worth reading twice.

The EXECUTE AGENT TASK privilege that governs this is granted to the PUBLIC role by default. Administrators can restrict it. Until somebody does, every user in the account can schedule an unattended agent.

I want to be fair to Snowflake here, because defaults are a genuinely hard product decision and they documented this clearly rather than burying it. But the practical reading for a technology leader is simple. If you run Snowflake, the answer to "can our people schedule autonomous jobs that run as themselves" is yes, today, and it did not require a procurement conversation or a security review.

That is not a Snowflake problem. That is the shape of every agent capability shipping right now. Features arrive enabled, scoped to whatever the platform already believes about who you are.

Nobody Is There to Say No

The third detail completes the picture.

Because the runs are unattended, interactive tool permission prompts are turned off. Tools available to the run execute without waiting for approval. Snowflake states the implication plainly and recommends against scheduling destructive or irreversible actions.

Sit with the combination. Broader identity than you tested, available to everyone by default, and no human in the loop at execution time.

Any one of those is manageable. The three together are how a Tuesday morning goes wrong.

Cron Taught Us This Already

The reassuring part is that none of this is new.

Every operations team that has ever run a scheduled job has been bitten by exactly this. The script worked when you ran it by hand and failed at 3 a.m. because cron had a different environment, a different path, a different user. We learned to ask which account the job runs as, what it can reach, and what happens when it fails with nobody watching.

That institutional knowledge did not evaporate because the job now contains a language model. It applies directly. The only thing that changed is that the job can now improvise, which makes the blast radius harder to predict but does not change a single question you should be asking.

If you have people who know how to review a cron job, you already have people who can review this. Point them at it.

What I'd Do This Week

Ask what your agents run as. Not what you tested them with. What identity executes on the schedule. If your platform separates those two, treat that as a finding, not a footnote.

Check whether the capability is granted to everyone. In Snowflake specifically, look at whether EXECUTE AGENT TASK is still on PUBLIC. In every other platform, ask the equivalent question and expect the answer to be yes.

Give scheduled agents their own service identity. Not a person's account. A purpose-built identity with grants scoped to the job, which is what you would have done for any other scheduled process.

Write down what a scheduled agent may never do. Deletes, schema changes, outbound sends, anything touching production customer data. Then enforce it in the grant, not in the prompt.

Put agents in your existing job review. You probably already review scheduled jobs somewhere. Add these to that list instead of inventing a new process.

The Part That Matters

The failure here will not look like a rogue AI. It will look like a helpful job running with more access than the person who built it intended, at an hour when nobody is awake.

We have been solving that exact problem since long before any of this.

Ask what it runs as. Then go check.