A new category of identity, not a new feature
Most security programs are built around two categories of actor: people, whose access is governed by identity and role, and applications, whose access is governed by service accounts and fixed permissions. An agent doesn't fit cleanly into either. It acts with the autonomy of a person but the always-on, never-sleeps availability of a service account, and it's frequently granted broad access because narrowly scoping it would limit what it's useful for.
Treating an agent as just another feature of an application under-secures it badly. The right mental model is closer to an employee with system access: what can this identity do, what should it never be allowed to do regardless of instruction, and how would we know if it started doing something it shouldn't.
Prompt injection is a real attack surface, not a lab curiosity
An agent that reads an email, a document, or a webpage as part of its task is also reading anything an attacker chooses to embed in that content. Instructions hidden in a document can redirect the agent's next action, and because the agent is acting with its own legitimate credentials, that redirected action doesn't look like an intrusion from the outside. It looks like the system doing its job.
This is the attack surface that most existing security tooling doesn't cover well, because it was built to detect unauthorized access, not an authorized system being talked into misusing its own authorization. Defending against it requires treating untrusted content the agent processes as a potential instruction channel, not just data, and constraining what actions can follow from it.
An agent with access to your systems is a credential with judgment attached. Most security programs weren't built to defend against either half of that.
Fahmid Khan, Chief Technology Officer
The quiet risk is over-provisioning, not exotic attacks
In practice, the highest-frequency risk we see isn't a sophisticated injection attack. It's an agent that was granted broad system access during a pilot, for convenience, and never had that access narrowed once it moved into production. Nobody made an active decision to over-provision it; the access just never got revisited.
The fix is unglamorous and effective: scope every agent's permissions to the minimum its current task requires, review that scope on the same cadence you'd review a person's access, and treat "it might need it later" as a reason to expand access later, not now.
What a defensible posture looks like
Every agent with system access should have a named owner, a documented and minimal permission set, and logging detailed enough to reconstruct exactly which actions it took and why, after the fact. That's not a new security discipline; it's the identity and access management discipline security teams already run, applied to a category of identity that's growing faster than most inventories are keeping up with.
The organizations getting ahead of this aren't the ones with the most sophisticated agentic AI. They're the ones who brought security into the design conversation before deployment, instead of auditing the agents after they were already load-bearing.
