AI agents are quickly moving beyond answering questions. Companies increasingly want them reading email, accessing databases, calling APIs, handling credentials, and taking actions without waiting for a person to approve every step.
That creates a security problem that looks very different from traditional software. An AI agent can interpret ordinary language as instructions, including language buried inside content created by people outside the organization. Give that agent broad permissions and long-lived credentials, and a manipulated agent could potentially do real damage at machine speed.
Sponsored Q&A: This article was produced as part of a paid sponsorship with Symmatrics. NERDS.xyz spoke with Dr. Gaurav Bhat, SVP of Symmatrics, about agent identity, short-lived credentials, encryption, prompt injection, quantum resilience, and what organizations should put in place before allowing autonomous AI anywhere near sensitive corporate data.
Companies are increasingly giving AI agents access to sensitive data and the ability to take actions autonomously. What new security risks does that create compared with traditional software?
Dr. Gaurav Bhat: Traditional software works on deterministic logic inside the code written by software developers. An agent decides what to do based on what it reads, mostly English sentences, and it reads everything in your emails, tickets, web pages, and documents written by people you don’t control. That means a sentence hidden in a document can become a command. On top of that, it has access to sensitive systems and the ability to act at machine speed.
So now, you’ve basically created a new kind of insider threat: one that is always trusted, tireless, and fully persuasible. The real risk isn’t from outside agents. It’s from these internal agents that are already inside your network, holding credentials that last far longer than any single task requires.
When people talk about a “rogue” AI agent, what does that actually mean from a cybersecurity perspective? Are you more concerned about compromised agents, poorly configured agents, or agents behaving in unexpected ways?
Dr. Gaurav Bhat: In security terms, a “rogue” AI agent has nothing to do with intent of the AI agent. It simply means an agent acting outside its intended purpose, for whatever reason. It may be compromised through a prompt injection or a stolen token. It may be misconfigured with far more access than it needs to do the tasks it was designed to do. Or it may pursue a legitimate goal down a path nobody anticipated or permitted.
Misconfiguration worries me most today because it’s the most common, and it turns the other two from incidents into breaches. An agent with narrow, short-lived access that goes wrong is still possible to contain because it is limited in time and scope. The same agent with broader or lifetime access is a security nightmare that can take your company down.
AI agents may need access to credentials, databases, APIs, and other sensitive systems to be useful. How can organizations give agents enough access to do their jobs without effectively handing them the keys to everything?
Dr. Gaurav Bhat: AI agents should not have the keys to everything. They should only have the permissions necessary to perform their tasks, and those permissions should expire automatically. IBM’s 2026 Cost of a Data Breach Report found that 92% of organizations hit by an AI-related breach didn’t have proper access controls on their AI systems.
Only provide access relevant to the scope and task at hand. So, basically, one agent should have access only to the required data and the limited actions it needs to perform, and only for a limited timeframe, typically a few minutes. Credentials should be issued just in time, bound to the specific agent and the specific machine it runs on, and there should always be a human in the loop for anything that is potentially irreversible.
If a credential is somehow stolen, the thief should find that it already expired, has no scope, and most importantly, was tied to a device they don’t have access to.
Symmatrics focuses on advanced symmetric encryption. How can symmetric encryption help limit the damage if an AI agent is compromised or begins behaving in ways its operator did not intend?
Dr. Gaurav Bhat: Symmetric encryption can’t stop an agent from being manipulated. It can, however, limit what a manipulated agent has access to and how long it has access. Most breaches don’t defeat pure encryption technologies. They are built to work around it, using keys and credentials that stay valid far too long.
At Symmatrics, we focus on the lifecycle of the key itself. Keys are generated fresh for a single session, delivered only to an enrolled and authenticated device, used, and then completely discarded, never to be reused. When we apply these keys to agents, an agent compromise would yield only what that agent could open in that moment, with nothing to replay the next moment. Revocation is also built into our system. The moment we stop issuing keys, access to anything and everything ends. The damage is bounded by very limited time and scope of the agent within a set boundary.
Encryption protects data, but an authorized AI agent may legitimately need to decrypt or access that information. How do you prevent the agent itself from becoming the weak point?
Dr. Gaurav Bhat: The idea is to always start by accepting that no encryption protects data from an authorized reader. With that in mind, design your systems around it. What that means is treating every decryption as an outside request, not an authorized one. So, let’s say the agent asks for a key for a specific task. Your policy then decides, in that moment, whether to provide that key, and it ensures the key expires when the task does.
Wherever possible, keep raw data/PII away from the model entirely, so the agent receives an answer like, “this customer qualifies,” instead of the full record. And, of course, log every key request. Any abnormal behavior then stands out very quickly, like a rogue agent suddenly opening tens of thousands of records it has never touched before.
Does securing autonomous AI agents require organizations to rethink traditional identity and access management, particularly when an agent may perform thousands of actions without a human approving each one?
Dr. Gaurav Bhat: Yes, this goes back to my earlier discussion. Identity and access management was built for human identities who log in once and remain trusted for hours, if not days. The only review gate that existed was that identities get reviewed every quarter, if at all. Compare this to an agent that can take thousands of actions before lunch and never see a multi-factor prompt. So, the overall trust model must change.
Firstly, agents need their own identities, each traceable to an accountable human. Secondly, authorization must happen on every action, not just once at login. And, most importantly, people should approve the policy rather than every step, with the system enforcing it continuously. Identity only tells you who someone or something is at a moment in time. With agents, the harder and most important question is how long that trust should last and who makes that decision.
AI agents can communicate with other agents and services. Does this agent-to-agent communication create a new attack surface that current enterprise security tools are poorly equipped to handle?
Dr. Gaurav Bhat: Yes, this is creating a massive attack surface, and it’s growing faster than most security teams may realize or pay attention to. Enterprise tools were built to watch people and networks, and it was very predictable: logins, endpoints, traffic at the perimeter, etc.
Agent-to-agent traffic looks like ordinary API calls, and its payload is often plain language that can carry instructions from one agent to the next. Trust becomes a chain reaction. If one agent accepts another’s output without question, a single compromise can ripple through an entire workflow and potentially the entire network.
Thus, every exchange in-between agents should be mutually authenticated and encrypted under its own short-lived keys. And, by default, every exchange should be treated as untrusted on arrival. We spent most of the last decade learning that “internal” doesn’t necessarily mean “trusted.” Agents are about to take this to a different level.
Symmatrics describes its technology as quantum-resilient. How immediate is the quantum computing threat for organizations deploying AI agents today, and should companies already be designing AI infrastructure around post-quantum security?
Dr. Gaurav Bhat: Quantum computing is advancing rapidly, and the threat from it is already here.
Adversaries can record encrypted traffic today and decrypt it once the hardware matures. This “harvest now, decrypt later” risk matters most for long-lived data, which is what many of the agents now have access to, including intellectual property, personal health records, and personal financial data.
So yes, companies should already be building for quantum resilience now. And always maintain perspective about the current environment: today’s agent breaches come from weak access controls and stolen credentials, not quantum computers.
The precise exposure is the public-key exchange that sets up most of the connections that exist today. Symmetric encryption with 256-bit keys is considered quantum-resistant. The logic behind our design is that once a device is enrolled, the keys it receives are protected by symmetric cryptography, not by that public-key exchange.
There is considerable attention around post-quantum cryptography and new cryptographic standards. Where does advanced symmetric encryption fit alongside those approaches rather than replacing them?
Dr. Gaurav Bhat: Symmetric encryption fits alongside these approaches as different layers, not as a direct replacement. Post-quantum cryptography, such as NIST’s ML-KEM and ML-DSA standards, replaces the vulnerable public-key pieces- that is, how two parties agree on a key and prove who they are. But every secure connection still relies on symmetric encryption to do the actual work.
Our focus is on fresh symmetric keys for every session, delivered only to verified devices and then discarded. The goal of post-quantum cryptography it to make the key exchange safe, while our goal is to make trust short-lived. Organizations planning for the next decade will probably want to implement both.
If an organization is deploying autonomous AI agents today, what are the most important security controls it should have in place before allowing those agents anywhere near sensitive corporate data?
Dr. Gaurav Bhat: Before an autonomous AI agent goes anywhere near sensitive data, I’d want these things in place:
- An inventory of every agent, what it can reach, and the human accountable for it.
- Its own identity. No shared accounts, no borrowed human credentials, no secrets hard coded into prompts or code.
- Access that is task-scoped and short-lived, bound to the agent and the machine it runs on.
- Human approval for anything irreversible, like payments, deletions, or sending data outside the company.
- Untrusted-input discipline. Assume anything the agent reads could be hostile, and test for prompt injection before launch.
- Complete logging and a kill switch, so you can see every action and cut off access in seconds.
- Real-time alerts for any discrepancies in Agent Actions.
If you can’t say what an autonomous AI agent can touch, for how long, and how you’d stop it, it isn’t ready.
Support independent tech journalism
NERDS.xyz is independently owned and operated. If you enjoy my coverage of Linux, AI, hardware, cybersecurity, and tech culture, consider supporting the site on Ko-fi.
Support NERDS.xyz


