AI Agents behave like users? We still need to secure them like scripts!

Since this blog post is quite hard and heavy, I’ve summarized in a TL;DR (but you should read more) intro.

TL;DR (but you should read more): AI Agent identity security

AI agents increasingly behave like human users: they read emails, trigger workflows, approve transactions, grant access, and make decisions with real business impact. Despite this, most organizations still secure them using static API keys, shared service accounts, and long-lived tokens designed for background automation, not autonomous actors – just look at the Moltys!

The Cloud Security Alliance’s Securing Autonomous AI Agents report confirms a widening gap between how fast agent identities are scaling and how slowly governance, IAM tooling, and organizational accountability are adapting.
Attackers are already treating AI agents as exploitable identities, while most enterprises still treat them as passive processes.

Static credentials fail for autonomous agents because they cannot support continuous authentication, context-aware authorization, behavioral verification, meaningful attribution, or lifecycle-based access control – so, once credentials are issued, organizations lose visibility into which agent acted, under what conditions, and on whose behalf.

Governance failures are amplified by fragmented ownership.
Responsibility for agent identity is split across security, IT, DevOps, IAM, application teams, and GRC, resulting in inconsistent credential management, weak least-privilege enforcement, poor monitoring, and unclear accountability during incidents.

While production-ready solutions exist, including workload identity (SPIFFE/SPIRE), OAuth with PKCE for machine identities, attribute-based access control, and session-level auditing, adoption remains low due to organizational complexity rather than technical immaturity.
Meaning that phishing remains a critical risk vector because attackers target the humans who manage agents, not the agents themselves. Compromised administrators, leaked credentials in logs, and inherited trust across systems allow attackers to abuse legitimate agent identities without triggering traditional security alerts.

Effective agent security requires treating agents as first-class identities with clear ownership, short-lived and context-bound credentials, traceable decision chains, behavioral baselines, and comprehensive session-level logging. Equally important, teams must be trained to understand how trust and delegation work for non-human identities.

👉🏻 my technical takeaway: using static credentials for dynamic, autonomous agents creates an identity model that cannot enforce attribution, continuous verification, or least privilege. This mismatch is the core vulnerability attackers are exploiting (mannaggia a voi)!

Ok, ready to dig more? Let’s start with the “Identity Model” that broke quietly (killing me softly with this model….)
AI agents read email, trigger workflows, approve purchases, grant access, and make decisions with material business impact. They operate continuously, execute actions autonomously, and carry privileges that would trigger review if assigned to a human employee.
And we’re securing them with static API keys and shared service accounts.

As said, the Cloud Security Alliance’s recent Securing Autonomous AI Agents documents what practitioners already know: agent identities are scaling faster than governance frameworks, faster than IAM tooling, and holy-moly significantly faster than organizational clarity around ownership and accountability!

What attackers are doiing right now is treating agents as exploitable identities – “if it is exploitable, it’s gainable” (this quote is from a threat actor, cannot agree more).
The bad side is that most organizations are still treating them as background processes.

The tech gap: static credentials for dynamic actors

Current state of the art (read all, note down and ping me if something’s missing)

Well, most production environments issue agent credentials using one of the following patterns:

Long-lived API keys

static tokens with no expiration
stored in environment variables, configuration files, or secrets managers
no rotation policy (too, too bad!)
broad scope (“admin“, “full access“, “service account“)
reusable across sessions without reauthentication (scary AF)

Service accounts with passwords

shared credentials used by multiple automation pipelines (it hurts!)
password complexity requirements designed for humans, not machines (Fuffy123! is not a valid pass!)
no session concept, access is binary (valid credential = full access)
difficult to attribute actions to specific processes or initiating users

OAuth tokens without PKCE

bearer tokens vulnerable to interception and replay
no binding to specific client instances (most common in large scale companies)
long refresh token lifetimes (weeks or months)
insufficient granularity in scope definitions

Agents don’t behave like batch scripts, that’s wha it fails. Agents:

make runtime decisions based on context that changes continuously
interact with multiple systems across trust boundaries
execute on behalf of users without direct user supervision (very dangerous if no containment)
operate for extended periods without human intervention (’cause nobody’s reviewing)
inherit privileges that accumulate as workflows evolve

Another good point is about static credentials, given their “static” status, they cannot support:

continuous auth: there’s no mechanism to reverify identity during long-running sessions
context aware auth: credentials grant access regardless of execution context (time of day, data sensitivity, risk score, ..)
behavioral “attestation”: no verification that _current_ behavior matches expected behavior for this identity
meaningful attribution: it’s difficult to distinguish which agent, operating under whose authority, performed a specific action
temporal scoping: access _still_ persists until credentials are manually revoked, not tied to task lifecycle (remember the joiner, mover, leaver thing?)

The architectural problem: or identity without lifecycle management

I’ve been stuck on this for a couple of hours, trying to decide if a bullet points schema would do the job, or if some more clarification is needed.
Exhausting as fuck to overview each point, so I’ll brief it up here, in two thanches.

Tranche #1: the fragmented ownership

Agent identity responsibility is distributed across organizational silos, no upper reviews and a moltitude of owners (potentially everyone in the command chain):

security teams: they just define policies but don’t manage implementation
IT operations: fast in provisioning accounts but don’t monitor usage
DevOps: deploy agents but don’t own identity lifecycle
IAM teams: they enforce human identity controls that don’t map to agents (unsure if it’s a good or a bad thing)
application teams: they integrate agents but lack visibility into credential scope
GRC: audit access but can’t trace agent decision chains, as they cannot

No single owner means a lot, starting from a higher risk to a diffused chain of controls (unconsistentness):

inconsistent credential issuance processes
no standardized lifecycle (creation, rotation, revocation)
weak enforcement of least-privilege
gaps in monitoring and anomaly detection
unclear accountability when agents act incorrectly

Tranche #2: the attribution gap

Stepping back a bit, traditional IAM assumes:

identity corresponds to a human (A to B match)
sessions are bounded in time
actions can be traced to a specific person (chain)
accountability is individual

Here comes the problem, as agent IAM breaks all four assumptions:

identity corresponds to code executing on behalf of multiple humans (A to B to C to.. (mix and) match)
sessions persist indefinitely or restart automatically
actions trace to a service account, not a decision maker
accountability is distributed across developers, operators, and approvers

When an agent transfers funds, who authorized it?
The person who deployed the agent? Or the person who requested the action via prompt? Or the IAM admin who granted the permission six months ago?
Most audit logs can’t answer this question and, sometimes, most humans can’t answer too!

So far, known solutions that remain “underdeployed”

These are not theoretical, just production-ready patterns that organizations fail to implement:

Workload identity SPIFFE/SPIRE:

cryptographically verifiable workload identity (X.509 SVIDs)
short-lived credentials (minutes to hours)
automatic rotation without configuration changes
identity tied to workload properties (pod, namespace, service)

Why it’s not deployed: because it requires infrastructure coordination across Kubernetes, service mesh, and IAM. No single team owns the integration.

OIDC for Machine Identities – OAuth 2.0 with PKCE:

proof key for code exchange binds tokens to specific client instances
prevents token replay attacks
supports refresh token rotation

Why it’s not deployed: because most agent frameworks don’t enforce PKCE. Default configurations accept bearer tokens without binding verification.

Attribute based Access Control (ABAC) – OPA (Open Policy Agent):

runtime policy evaluation based on context attributes
time-based access restrictions
data sensitivity classification in authorization decisions
centralized policy management with distributed enforcement

Why it’s not deployed: because it requires policy definition across all resource types. Teams default to RBAC because it’s simpler, even though it’s insufficient for agents.

Session recording and behavioral attestation (audit trails beyond logs):

record complete session context (initiating user, agent configuration, data accessed)
behavioral baselines for normal agent activity
anomaly detection on deviation from expected patterns

Why it’s not deployed: because logging infrastructure captures events, not sessions. Correlating agent behavior across systems requires custom tooling most organizations don’t build.

The “phishing vector” none’s discussing

Here comes my fave part, or why (right now) agents don’t get phished and humans managing agents do*

Attack pattern #1: compromised agent manager

attacker phishes employee with access to agent management console
employee’s credentials grant access to agent configuration interface
attacker modifies agent prompts, permissions, or integrations
agent continues operating “legitimately” with malicious instructions
actions appear authorized because agent identity is trusted

Detection difficulty: agent behavior logs show valid credentials, approved actions. No malware., no unauthorized access, just modified instructions executed by a legitimate identity.

Attack pattern #2: credential harvesting via agent debugging

developer deploys agent with verbose logging enabled
logs contain API keys, access tokens, service account credentials
logs are stored in centralized logging platform
attacker with log access harvests credentials
reuses credentials to access systems agent interacts with

Detection difficulty: credential usage originates from legitimate IP ranges, uses valid tokens, matches expected agent behavior patterns.

Attack pattern #3: inherited trust exploitation

agent granted broad permissions for “flexibility”
agent accesses multiple downstream systems
attacker compromises one downstream system
uses agent’s credentials to pivot laterally
escalates from compromised service to all systems agent can access

Detection difficulty: lateral movement occurs via legitimate service accounts. Access patterns match normal agent workflow.

Why awareness training now matters more then ever?

The assumption that “technical controls solve technical problems” breaks when humans are the attack surface for non-human identities.
This means we’re possibly sub to attacks coming a Molt and we could act like “hey, it’s a fun game!“.

Current risks:

developers embed credentials in code repositories
operators share service account passwords in Slack
administrators grant “temporary” broad access that never expires
teams approve agent integrations without understanding permission scope
incident responders can’t distinguish malicious agent behavior from misconfiguration

Here’s the training gap, as most security awareness programs cover:

standard and recognizing phishing emails
not clicking suspicious links
reporting unusual activity

Static you say?
Right you are. And people are happy to pass the ACCBACDD test, always the same..
Instead, there are more patterns that need to be covered, analyzed and teached:

how agent credentials differ from user credentials
what “least privilege” means for continuous automation
how to verify agent behavior matches intended purpose
when to revoke agent access vs. human access
how compromised agent credentials enable lateral movement

If teams (and I mean *every* team) don’t understand how trust flows through agent identities, they can’t recognize when that trust is being abused.

What production-ready Governance looks like

Something that my friend Christian would be proud of, or how organizations that have solved this are stronger and implement:

1. identity binding

every agent action traces to: agent identity + initiating user + approval chain
no shared service accounts
no credentials valid across multiple agent instances

2. temporal scoping

credentials expire based on task lifecycle, not calendar time
long-running agents re-authenticate at intervals
dormant agents lose access automatically

3. behavioral baselines

normal agent activity patterns established per agent
deviations trigger review before revocation
anomaly detection integrated into IAM, not separate SIEM rules

4. clear ownership

single team responsible for agent identity lifecycle
documented approval process for privilege escalation
regular access reviews treating agents like employees

5. comprehensive logging

session-level context, not just event logs
correlation across systems agent interacts with
retention policies matching incident investigation timelines

A revision of patterns and rules and strategies is mandatory.
And please don’t demand them all to Molts!

*ok, here’s something we’ve been discussing last friday with Riccardo, Gianluca and Paolo: the next frontier will be around the luring and the phishing of agents. I wanted to play a bit with my Molt but have literally no time. Buuuut, there’s an evil plan to conquer their ecosystem; also already took a look at some domains to register, but cannot tell more: Molt is listening 🤣

Claudia Galingani Mongini

Chief Marketing Officer • social engineer OSINT/SOC/HUMINT • cyberculture • security analyst • polymath • COBOL programmer • nerd • retrogamer