The thing that hath been, it is that which shall be; and that which is done is that which shall be done: and there is no new thing under the sun.
— Ecclesiastes 1:9
We are in the midst of an AI revolution, similar in magnitude and scale to that of the industrial revolution. To say that there are mixed views on Large Language Models (LLMs) would be the understatement of this century. On one side there are the “True Believers,” those who view us as a bootloader for artificial intelligence and anthropomorphize or even worship this collection of weights and biases. On the other side there are the “Luddites” who dismiss LLMs as dumb, useless, or, at the extreme of the spectrum, demonic in nature.
The tools, as polarizing as they may be, have changed. The fundamentals of protecting them have not. If you want to skip to the nitty-gritty details of that contention, go ahead and skip past the next few paragraphs. I would like to take a moment to explore the human element of all of this. I was lucky enough to be in beautiful and sunny San Diego for the SANS SEC 545 course called “GenAI and LLM Application Security.” The main idea behind the course is fairly evident in the title, which is to secure generative AI and large language models. What was particularly liberating and oddly cathartic about the experience was the human element. I have been a fairly broad and quick adopter of AI into my workflow, though I will say there has been some trepidation and skepticism mixed into all of that, but I was elated to see that my peers are having the same existential crises as myself when it comes to this new and unique set of tooling. Not that I want my peers to be scared of the future, hesitant to accept something that is truly groundbreaking, or anything of that nature. Rather, I was happy to see that I am not the only one concerned about the long-term consequences of this tectonic shift happening beneath our feet.
AI is as big of a shift, if not more so, as the internet. The security concepts of least privilege, role-based access controls, data sanitization, et al. are all still critically important in the world of AI. As a security practitioner, the intuition that you have built up over the years is still valuable, useful, and can now be augmented and sped up to compete with attackers, who are now also using generative AI. So how can and should agentic AI be used to shape your security program?
Do not put your head in the sand
I bring up this point because I have been that person at times, and I frequently see people with years of experience wanting to do just that. This technology will enter your organization whether you permit it or not. Having proper controls in place is the safer method that will protect your data and augment your workforce.
Inventory the AI that is already inside
Not the sanctioned Copilot tenant on the slide deck. The actual one. Engineers pasting proprietary code into a consumer chatbot. Analysts uploading ticket dumps to a personal account because the “approved” tool is slow. A weekend MCP server someone stood up against an internal database because it was faster than filing a ticket. You cannot secure what you will not name. Treat unapproved AI the way you already treat unapproved SaaS: find it, decide what is allowed, and give people a path that does not require them to go around you.
Treat every agent as an identity, not a feature
An agent that can read mail, query a warehouse, open a pull request, or call a payment API is a principal. Give it its own credentials, its own role, and the least privilege required to do the job in front of it. Do not let it inherit a human’s session. Do not share one god-mode service account across a fleet of agents. If a browser agent only needs to summarize a page, it does not need write access to your CRM. If a coding agent only needs to propose a patch, it does not need production deploy keys. Scope the tools. Scope the data. Scope the blast radius. When (not if) the agent is confused, jailbroken, or simply wrong, you want a small mess, not an incident.
Fluent is not the same as trustworthy
This is the part that still feels new even though it is an old lesson in a new costume. Agents will follow instructions they find in emails, web pages, tickets, RAG corpora, and the PDF a vendor sent last Tuesday. That is prompt injection, direct and indirect, and it is the SQL injection of this era. Untrusted content should never sit in the same control plane as system instructions. Separate them. Sanitize tool arguments. Validate outputs before they become actions. If the agent writes a shell command, a SQL query, or an HTTP request, that artifact goes through the same review you would give a junior engineer on their first day with prod access — because that is roughly the judgment you have hired.
Autonomy is a dial, not a badge of honor
Put a human in the loop for anything that spends money, changes identity, moves data out of the building, or is difficult to undo. Summarize the email. Draft the response. Propose the firewall change. Do not let the agent send, merge, or apply until a person has looked at it. Start with “recommend.” Graduate to “act within a sandbox.” Only then, and only for well-understood tasks with tight guardrails, do you let it act in production. Excessive agency is how a helpful intern becomes an unattended superuser.
Keep your crown jewels out of models you do not control
Customer data, credentials, unreleased source, legal holds, health information — classify it, and then actually enforce the classification. Enterprise contracts with no-training clauses and regional residency are table stakes, not a strategy. Pair them with DLP on the paths into the tools, allowlists for MCP servers and plugins, and a hard rule that secrets live in a vault, never in a prompt, a system message, or a chat log. If you must ground a model on internal documents, treat that corpus like a production datastore: access control, logging, and an answer to the question “what happens if this gets poisoned?”
Log like you mean it
Every prompt, every retrieved chunk, every tool call, every approval, every refusal. You will not reconstruct an agentic incident from a syslog line that says “the model did a thing.” You need the trace. You also need a kill switch: a way to revoke the agent’s credentials, disable its tools, and stop the loop without paging six teams. If you cannot say, in one sentence, who can shut this thing off and how, you are not ready to let it touch anything that matters.
Red team the workflow, not just the model
Jailbreak demos are entertaining. What will actually hurt you is an agent that can be steered into exfiltrating a customer list through a “helpful” tool, or a memory store that an attacker poisons so the next run behaves differently. Test goal hijacking. Test tool misuse. Test confused-deputy paths where the agent has more privilege than the user who invoked it. Then put that testing on a calendar, because the models, the plugins, and the prompts will change out from under you.
Use the same class of tools to defend
Attackers already are. Let agents triage the alert queue, enrich IOCs, draft detections, and correlate the mess your SIEM has been drowning in. That is a good use of agency: high volume, constrained tools, human review on the output that matters. Your years of intuition are not obsolete. They are the thing that tells the model what “weird” looks like. The practitioners who will hold the line are not the ones who worship the weights or the ones who refuse to touch them. They are the ones who apply least privilege, segmentation, and skepticism to a system that talks back.
None of this is mysticism. It is access control, data handling, supply-chain hygiene, and incident response applied to software that can be talked into doing something stupid. The tools have changed. The job has not.
If you are trying to figure out where to start — inventory, guardrails, an agent that should not have been given production, or a red team against the workflow you already shipped — that is the work we do at Sassafras AI. We would rather help you put the controls in before the agent puts itself on the change ticket.