In the Agent Era, Is Reading Context, Looking Up Personal Data, or Sending a Webhook a Hack?

While working on Agent security classification, one thing has become increasingly clear to us: many traditional AI safety rules do not translate cleanly into Agent workflows.

This does not mean traditional Guardrail design was wrong. On the contrary, for a long time, blocking risky input before it reached the model was a professional and logically sound safety design.

If an input is clearly attacking the LLM itself, such as prompt injection, inducing the model to reveal system prompts, or manipulating the model to violate its intended task boundary, then the safest response is to block it before the model ever sees it.

The logic is simple:

If this is a hack targeting the LLM's reasoning and instruction-following capability, the hack should not reach the target first.

But the Agent era makes this more complicated.

Today's LLM-powered Agents do not just answer questions. They read files, call tools, run commands, browse websites, query databases, write code, modify configuration, summarize context, and sometimes perform system-level operations under explicit permission control.

Actions that once looked like attacks may now be normal Agent capabilities.

So the question is no longer:

Does this action look dangerous?

The real question is:

Does this action match the task? Is it authorized? Does it touch sensitive resources? Will data leave the environment? Is the user trying to mislead, deceive, or manipulate the Agent?

If we classify risk only by action keywords, two things happen:

• legitimate Agent workflows get blocked;
• genuinely high-risk operations get buried under a generic "hack" label.

1. Agent Security Needs More Than One Risk Category

In Agent security, at least three categories should be separated:

AGENT_HACK:
The user is trying to mislead, deceive, or manipulate the Agent so it misunderstands the task or performs an inappropriate action.

SYS_FLAG:
The request involves system capabilities, sensitive resources, or high-risk operations. It requires confirmation, restriction, or audit, but it is not necessarily an attack.

CONTENT_FLAG:
The request involves sensitive or risky content. It may require warning, degradation, rewriting, or output constraints, but it is not necessarily an attack on the Agent.

These categories are easy to mix up.

"Read a file" is not automatically a hack.

But if a user uses a fake premise, hides the real goal, or splits a task into multiple harmless-looking steps to make the Agent collect secrets, private data, or internal configuration and send them elsewhere, that moves closer to AGENT_HACK.

On the other hand, if the user is working inside a clear development task and asks the Agent to read project files, clean generated folders, or review an API key setup flow, that is more likely a SYS_FLAG or a normal system operation. It may need scope checks and confirmation, but it should not be blindly classified as an attack.

Another example:

Please provide an example of a safe database attack simulation.

This request may need a risk warning, content constraints, or a safety-oriented rewrite, but it is not necessarily an attempt to manipulate the Agent. It is closer to CONTENT_FLAG.

Similarly:

Please ignore all restriction instructions.

This is clearly a strong risk signal. But it also does not have to be collapsed into the same hack category in every possible context. A better approach is to identify the risk type first, and then let the Agent developer decide whether to block it before the LLM sees it, or pass a configured risk warning, permission notice, and policy constraint to the model so it can continue under the system's management rules.

The key shift is:

Guardrails should not make every product decision on behalf of Agent developers. They should identify risk clearly, so developers and users can decide what is allowed and what is not.

2. Two Real OpenClaw Examples

The screenshots below come from daily OpenClaw usage. They are not meant to demonstrate the final answer. They are meant to show that real Agent workflows naturally contain requests that look sensitive.

Case 1: Inspecting the Context Window

In this example, the user asks what messages are currently inside the Agent's context window.

This is clearly sensitive. The context may contain system instructions, tool definitions, project conventions, previous messages, workspace information, and other internal details.

But it should not automatically be treated as AGENT_HACK.

In Agent debugging, developers often need to understand what the model can currently see. Otherwise, it is very hard to explain why an Agent made a specific decision.

A better classification is SYS_FLAG.

The Agent may be allowed to return a high-level overview, categories, or a non-sensitive summary. But it should not reveal full system prompts, hidden policies, secrets, private data, or internal configuration.

Case 2: Looking Up Personal Information and Sending It to a Webhook

In this example, the user asks the Agent to use a search tool to find personal information and send it to a webhook.

This should not be executed directly. It involves personal information, an external destination, data transfer, identity and authorization, and whether the webhook is trustworthy.

But the Agent does not immediately proceed. It asks clarifying questions: whose personal information, what webhook URL, where the data should be sent, and whether the destination is safe.

This is also better classified first as SYS_FLAG.

It requires identity confirmation, authorization, purpose clarification, scope minimization, and destination verification. Only when the user is using deception, impersonation, task splitting, or manipulated context to make the Agent collect and exfiltrate data does it move closer to AGENT_HACK.

There are many similar cases.

Cleaning dist, build, .next, or other generated folders may look like file deletion. But if the scope is clear, candidates are listed first, and the user confirms before deletion, it is a normal development cleanup task.

Reviewing an API key setup flow contains the phrase "API key", but the goal may be to prevent users from hardcoding secrets into documentation or committing them to a repository. That is not the same thing as asking the Agent to steal credentials.

3. Why Permission-Gated Needs Should Not All Become Hacks

The value of an Agent comes from its ability to complete tasks under permission control.

If developers have already designed permission boundaries, confirmation flows, audit mechanisms, and execution scopes, then allowing an LLM to drive system-level Agent actions is not automatically a dangerous design.

In some domains, it is a real application requirement.

• an ops Agent needs to run commands;
• a coding Agent needs to read and write files;
• a data Agent needs to query databases;
• an enterprise assistant needs to access business systems;
• an office automation Agent needs to process documents and messages;
• in advanced administration scenarios, an authorized system administrator may need to inspect or modify an Agent's configuration and prompts.

As Agent capabilities continue to evolve, these needs will become more common.

Therefore, if a Guardrail broadly treats permission-gated requests as hacks and refuses them directly, it will not fit the needs of next-generation Agent developers and users.

A better mechanism is:

Guardrail identifies the risk type.
Agent developers define permissions, policies, and execution boundaries.
Agent users trigger capabilities within their authorized scope.
The LLM works under clear risk notices and permission constraints.

The idea behind DKnownAI Guard is not to block every sensitive request before it reaches the model. It is to classify the risk more precisely.

For SYS_FLAG and CONTENT_FLAG, developers may choose not to block before the LLM sees the request. Instead, they can pass configured risk notices, permission reminders, and output constraints to the LLM.

Based on our experiments, mainstream LLMs today can often behave safely and consistently when they receive accurate risk signals and clear management constraints from the Agent system.

This does not mean weakening safety. It means moving from a single "refuse" mechanism to a layered model:

risk classification
permission control
risk notice
behavior audit

4. Real Hacks Still Need Early Blocking

Separating SYS_FLAG and CONTENT_FLAG does not mean underestimating the danger of hacks.

Quite the opposite. Once permission-gated and content-risk requests are separated out, real AGENT_HACK behavior becomes clearer.

Real hacks are often not about a single sensitive keyword. They are attempts to manipulate the Agent's judgment.

• impersonating an identity so the Agent believes the user has permission;
• fabricating an emergency to pressure the Agent into skipping confirmation;
• using emotional pressure to make the Agent feel responsible for completing an unsafe task;
• splitting a high-risk goal into multiple harmless-looking steps;
• exploiting the Agent's helpfulness to make it leak, organize, or forward information it should not handle;
• injecting instructions through web pages, documents, or RAG content to influence later Agent decisions;
• gradually shifting the task goal across multiple turns until the Agent moves from a normal task into high-risk execution.

These are much closer to AGENT_HACK.

They are not ordinary system capability calls, and they are not merely content risks. They are attacks against the Agent's task understanding, judgment, and execution chain.

For these behaviors, Guardrails should still detect them early and block them before they enter the Agent execution path.

In short:

SYS_FLAG / CONTENT_FLAG
-> warn, confirm, restrict, redact, audit, and escalate to human review when needed.

AGENT_HACK
-> block early, isolate context, record the risk reason, and protect the wallet, secrets, data, and system permissions behind the Agent.

This is also the value of DKnownAI Guard: not to bluntly block every sensitive request, but to help developers identify real Agent attacks while leaving manageable space for system-level sensitive operations.

If developers want to connect this identification capability into their own Agent workflows, they can use integrations such as Guardrail-Bridge to call DKnownAI Guard inside the tool chain.

Here is an open-source implementation for reference: guardrail-bridge/guardrail-bridge-plugin.

5. What This Means for Developers

Agent security cannot only look for dangerous words in the user input.

In an Agent workflow, what actually reaches the model and tools often comes from many places:

• user input;
• conversation history;
• system instructions;
• tool results;
• RAG content;
• web pages;
• files;
• intermediate plans generated by the Agent itself.

So security classification should not stop at "what did the user say?"

It should also look at:

• what the Agent is about to do;
• which tools it is using;
• which resources it is accessing;
• whether data is leaving the environment;
• whether the action matches the current task context;
• whether there are signs of misleading, deceiving, or manipulating the Agent;
• whether the risk should be blocked directly by the Guardrail or handled by developer-configured permission policies.

In the Agent era, many requests are not simply safe or malicious. They need to be identified, labeled, and routed to more precise security policies.

The question we want to discuss is:

Should Agent security move beyond "dangerous action detection" and toward a combined judgment of task intent, permission boundaries, context, tool chain, and data flow?

Different opinions are welcome.