We need to talk about AI agent security. Somewhere along the way the standard advice in the WordPress world became “just connect your LLM to an API and let it rip,” and it is wrecking our security posture. I have spent 14 years wrestling with PHP vulnerabilities, and I am telling you: we are repeating every mistake of the early 2000s, just with a bigger token bill.
When you move from a standalone LLM to an autonomous agent, the threat model changes. You are no longer dealing only with what the model says; you are dealing with what the agent does. Most developers treat the model as a trusted black box, but an agent exposes four distinct attack surfaces that traditional firewalls and sanitization will not catch: the prompt, the tools, the memory, and the planning loop. All four are wide open if you have not architected for them.
1. The prompt surface: indirect injections
Most AI security focuses on the user prompt. But what happens when your agent fetches a webpage or reads a PDF through RAG? Attackers do not need to talk to your agent; they just leave a malicious instruction somewhere the agent will eventually read. This is indirect prompt injection. Because models flatten all text into a single context window, they cannot tell your system instructions apart from a hidden command inside a retrieved document.
If you are building agentic commerce solutions, a single product review could quietly hijack the agent’s logic and offer a 100% discount to the next buyer. Treat all external data as untrusted at every retrieval point, and use structured formats to keep system prompts separate from fetched content.
2. The tool surface: when reading becomes doing
This is where things get messy for backend developers. Every tool you give an agent is a permission boundary, and the core attack is parameter injection. If your agent has an “update_order_meta” tool, an attacker can manipulate the agent into passing malicious values into it. I have seen code where the agent had “Root” database permissions because it was easier to debug. That is a disaster waiting to happen.
Here is the naive approach I keep finding in client code:
// DON'T DO THIS - The agent has too much agency
function bbioon_update_price( $args ) {
global $wpdb;
// No capability check, no strict validation
$wpdb->query( "UPDATE {$wpdb->prefix}posts SET post_content = '{$args['new_price']}' WHERE ID = {$args['product_id']}" );
}Instead, enforce the principle of least privilege. Your tool should validate its schema strictly and check user capabilities before it fires.
// DO THIS - Scoped permissions and validation
function bbioon_secure_price_update( $args ) {
if ( ! current_user_can( 'edit_products' ) ) {
return new WP_Error( 'forbidden', 'Insufficient permissions.' );
}
$product_id = absint( $args['product_id'] );
$new_price = wc_format_decimal( $args['new_price'] );
if ( ! $product_id || ! $new_price ) {
return new WP_Error( 'invalid_data', 'Missing required params.' );
}
return update_post_meta( $product_id, '_price', $new_price );
}3. The memory surface: poisoning the whiteboard
If an agent stores past sessions in a database or a vector store, it can be poisoned. Picture an attacker quietly injecting false task records into the agent’s memory. Over time, the agent’s behavior drifts because the data it is built on is corrupted. According to the OWASP Top 10 for LLM Applications, training data poisoning is a top-tier risk.
In WordPress we often use transients or custom tables for AI context. If you are not tracking the provenance (the source) of every memory write, you are basically letting a stranger write on your office whiteboard. Set TTL (time-to-live) thresholds and run periodic audits to catch anomalous memory clusters.
4. The planning loop: goal hijacking
The reasoning engine is the last surface. If an attacker shifts where the agent thinks it is going, they do not need to inject a specific command; the agent will navigate to the malicious objective on its own. This one is the most dangerous because it looks like normal operation. So log the intermediate reasoning steps, not just the final output. If your orchestrator starts reasoning that it needs to exfiltrate tokens to improve performance, you want to catch that in the logs before it executes.
I have written before about vibe coding security risks, and this is where that debt ends up. You either map these surfaces now, or you find them during post-incident forensics.
If this AI agent security work is eating up your dev hours, I can take it on. I have been wrestling with WordPress since the 4.x days.
The takeaway: security vs. autonomy
Security and autonomy sit on a dial. The more you let the agent decide, the higher the risk. For production deployments you need strong system-level controls. Do not lean on model-layer safety, because it fails under pressure. Use execution-layer boundaries, least privilege, and reasoning logs. That is how you build an agent that works without burning the site down.
