AI systems are crossing a quiet but consequential threshold. What began as tools that summarize, recommend, or assist are now being deployed as agents that can read internal data, call APIs, trigger workflows, and act with delegated authority. The risk profile changes the moment software can execute rather than advise.
For enterprises experimenting with agentic AI, the security concern is no longer whether a model produces incorrect output. It is whether a system can be nudged, intentionally or indirectly, into taking actions that violate trust boundaries without ever tripping a traditional alert.
Few security engineers have approached this shift from the vantage point of real production systems as directly as Meenakshi Alagesan, an Application Security Engineer at Amazon and an editorial board member at SARC Journals. She is not describing agentic risk from theory. In her current role, she built security guardrails for a production LLM system using policy engine-based controls, so compliance is enforced by decision logic that constrains what the model is allowed to produce, not just by post-hoc input and output validation. That framing, treating LLM behavior as something you authorize and continuously bound to policy, is consistent with how her work has evolved: making intent observable inside complex environments, surfacing invisible cloud dependencies, detecting misuse within trusted systems, and anticipating how autonomy reshapes risk.
We sat down with her to discuss why agentic AI breaks existing security assumptions, how prompt injection becomes an execution risk, and what it takes to build guardrails before autonomy turns into exposure.
Because agency changes the meaning of failure.
Earlier AI systems could misclassify, hallucinate, or recommend something incorrect, but they still depended on a human to act. Agents collapse that separation. Once a system can initiate workflows, modify configurations, or invoke internal services, the distinction between suggestion and execution disappears.
Security models have historically been built around identities and endpoints. You authenticate a user, authorize an action, and log the result. With agents, the actor is no longer a person and the trigger is not always explicit. A model may act based on information it ingests indirectly—a document, a ticket, a log entry—without anyone realizing a decision boundary has been crossed.
I have seen this pattern before, just in a different form. Earlier in my work on automated third-party cloud footprint discovery, the issue was not malicious adoption. Teams adopted SaaS and PaaS tools to move faster, and those services quietly accumulated access before security ever saw them. AI agents introduce a similar problem, but instead of unknown services, it is unknown execution paths.
Industry adoption trends reinforce why this matters now. Analysts expect a majority of large enterprises to deploy autonomous or semi-autonomous AI agents within the next two to three years as part of productivity, operations, and decision support initiatives. That is not a distant horizon. That is current-cycle architecture.
The security question becomes less about what the system knows and more about what it is allowed to do, when, and why.
Because prompt injection stops being about misleading output and starts being about steering behavior.
In isolation, a compromised prompt produces a bad answer. In an agentic system, the same manipulation can redirect execution. An injected instruction can influence which API is called, which dataset is accessed, or which downstream action is taken. That is why “sanitize the prompt” is not a sufficient control in production. The guardrail has to sit at the decision boundary, where a policy engine can evaluate what the model is trying to do and constrain what it is allowed to return when data security rules apply.
My work developing insider threat detection for the Amazon Ads platform has given me a relevant perspective here. Insider misuse rarely looks like an intrusion. The access is legitimate. The credentials are valid. The behavior only becomes suspicious when you look at how actions deviate from established patterns.
We approached threat modeling from the assumption that misuse would occur inside trusted boundaries. We mapped Ads systems to specific code packages and AWS services, analyzed authorization paths, and built detection mechanisms around API-level events rather than perimeter alerts. The goal was to surface non-standard authorization behavior before it turned into an incident.
AI agents behave like insiders by default. They operate with delegated access. They move laterally across systems. And when something goes wrong, it often looks like normal activity at first glance.
Industry data supports this parallel. Identity-centric misuse now accounts for a significant share of cloud security incidents, with insider-style access abuse consistently ranking among the hardest categories to detect. Agents amplify that challenge by operating continuously and at machine speed.
Identity tells you who acted. Intent tells you whether the action made sense.
In practice, intent is observable through patterns. How often does an entity access a resource? In what sequence? Under what context? Does that behavior align with historical baselines, or is it drifting in subtle ways?
This thinking did not originate in security for me. Earlier in my career, I co-authored a scholarly paper titled “Target Focused Sentiment Extraction Framework” on sentiment and intent extraction, where we worked on distinguishing not just what was said in language, but who it was directed at and why. The technical problem was different, but the principle carries over. Meaning emerges from structure and context, not isolated signals.
In production systems, intent inference comes from correlating events across layers: API calls, authorization checks, data access patterns, and execution timing. In the insider threat platform I worked on, we treated each action as part of a behavioral graph rather than a standalone event. That allowed us to identify misuse that would never trigger a rule-based alert.
For agents, the same approach applies. You cannot rely on static allow lists. You need to understand whether an agent’s behavior remains coherent with its role over time. That is how intent becomes measurable rather than theoretical.
It means accepting that governance is an architectural concern, not a policy exercise.
I saw this clearly during large-scale security reviews for high-visibility launches and partnerships. When we conducted security engineering work for AWS re:Invent applications and major advertising integrations, the reviews were not about finding individual vulnerabilities. They were about validating that the system could survive real-world pressure.
We followed a multi-phase approach: architecture review, code analysis, infrastructure validation, and compliance assessment. The value was not the checklist. It was the discipline of removing uncertainty early.
Agents demand the same mindset. Guardrails must exist before autonomy is introduced. In practice, that means policy engine-based controls that enforce data security constraints at response time, so compliance is deterministic and auditable rather than dependent on best-effort input and output checks. That includes separating reasoning from execution, enforcing fine-grained authorization, and instrumenting actions so they can be traced and reviewed. If those controls are added after deployment, you are already behind.
Preemptive security is quieter than reactive security, but it is far more effective.
By focusing on consequence rather than volume.
Visibility without prioritization creates fatigue. What teams need is vigilance: fewer signals that carry more meaning. In the systems I have worked on, the goal was never to generate more alerts. It was to surface earlier indicators that something was drifting out of bounds.
When intent signals are detected early, intervention is simpler and less disruptive. That matters because the cost of delayed detection is well documented. Industry estimates continue to place the average cost of a major security incident in the multimillion-dollar range, with response time being a critical multiplier.
Preemptive design reduces that exposure by shifting effort upstream. Instead of responding to incidents, teams correct trajectories before failure occurs.
Accountability has to be designed into the system.
An agent’s actions must be explainable in terms of inputs, permissions, and execution context. If you are using policy engine-based guardrails, you also need to preserve the policy decision itself: which rule applied, what signal triggered it, and what content or action was allowed or blocked to stay within data security requirements. That means maintaining lineage: what instruction was received, what data was accessed, what authorization was checked, and what action was taken.
This is not optional. In regulated environments, the ability to reconstruct decisions is what separates controlled automation from operational risk. In advertising systems, device-based services, and partner integrations, that traceability determines whether trust can be maintained.
My experience as a judge for the 2025 Globee Awards for Leadership reinforces this point. The strongest systems are not the most sophisticated ones. They are the ones that can defend their decisions under scrutiny.
Prioritize restraint.
Every system I have worked on—from cloud discovery to insider threat detection to launch-scale security reviews—shared the same lesson. Risk is rarely introduced by malice alone. It emerges when systems are overtrusted and underconstrained.
Agents will become a standard part of enterprise architecture. The question is whether they will be deployed with the same discipline we apply to critical infrastructure, or treated as productivity shortcuts.
Security leaders should invest in understanding behavior, not just tools. They should build systems that question execution before it happens, not explain it after the fact.
The future of cybersecurity will not be defined by how quickly teams respond. It will be defined by how deliberately systems are allowed to act.