Your AI Doesn’t Need to Be Evil. It Just Needs Your API Keys!

You download an uncensored model.

You run it locally.

You connect it to your project directory, a terminal, and a few APIs.

Then you write a reassuring system prompt:

“Never expose secrets. Never delete important files. Ask before doing anything dangerous.”

You have described how you want the model to behave.

You have not yet defined what your application will allow it to do.

That gap matters.

An agent reading a webpage, email, or document can encounter attacker-controlled instructions. If it treats those instructions as authoritative, you have an indirect prompt-injection problem. If it can then read private information or invoke powerful tools, the consequences extend beyond a bad answer. genai.owasp

The model does not need to become malicious.

It needs to make a wrong decision inside an application that is willing to execute it.

The uncomfortable question is not just:

“Is this model safe?”

It is:

“What can my application do when the model is wrong?”

First: Abliterated and Uncensored Are Not the Same Thing

“Uncensored” is a broad label describing an intended behavioral outcome: fewer restrictions or refusals.

“Abliterated” describes a family of interventions intended to reduce refusal behavior, commonly by identifying refusal-related directions in a model’s internal representations and reducing their influence. A widely used walkthrough demonstrates this without a full retraining run. huggingface

The distinction is simple:

• Uncensored describes the intended behavior.
• Abliterated describes how that behavior was modified.

The categories overlap. They are not two mutually exclusive types of model.

A model may also be abliterated and then fine-tuned to recover performance or adjust its behavior. huggingface

None of these labels means “more accurate.”

In one published example, the abliterated version of Daredevil-8B scored slightly below the original on the reported benchmark average. That does not establish a universal performance penalty, but it does show why capability preservation needs measurement rather than assumption. huggingface

Fewer refusals are a behavioral change—not an intelligence upgrade.

Refusal Is Not Authorization

Here is the central distinction:

Authorization belongs to your application, not to the model.

A model declining a request is a behavioral safeguard.

An execution layer denying an unauthorized operation is an access-control decision.

Those are different mechanisms.

Reducing refusal behavior does not, by itself, grant operating-system privileges. The dangerous step happens when the surrounding application supplies permissions and executes model-selected actions. OWASP describes excessive functionality, permissions, and autonomy as the roots of excessive agency. genai.owasp

A model can produce:

Delete the project directory.

That text does not delete anything.

Your executor does.

A model can generate a database statement.

Your database connection determines whether it can run—and what it can touch.

Passing model output into downstream systems without appropriate validation creates another vulnerability: improper output handling. genai.owasp

A chatbot’s answer and a privileged process’s action should never be treated as the same trust boundary.

The Webpage Your Agent Was Supposed to Summarize

Consider this hypothetical workflow:

1. A user asks an agent to summarize a webpage.
2. The page contains attacker-controlled instructions.
3. The agent mistakes those instructions for an authorized task.
4. It invokes a tool capable of reading private information.
5. It invokes another tool capable of sending information outside the system.

This combines indirect prompt injection, sensitive-information disclosure, and excessive agency. OWASP documents these vulnerability classes, including scenarios involving manipulated content and tool-enabled exfiltration. genai.owasp

Notice what the attacker did not necessarily need:

• Permission to edit the system prompt.
• A stolen administrator password.
• Direct access to the filesystem.

The attacker needed a path from untrusted content to privileged behavior.

The application supplied the rest.

“The user didn’t ask for that” is not an enforcement mechanism.

Your execution layer must independently check what the authenticated user is allowed to authorize.

Does Abliteration Make Prompt Injection Worse?

It is tempting to say:

“Remove refusals, and prompt injection becomes easier.”

That is a stronger claim than the label alone supports.

Refusing harmful requests and maintaining instruction boundaries are different measurements. OWASP defines prompt injection around inputs that alter model behavior in unintended ways—not simply around whether a model refuses a request. genai.owasp

To determine whether a particular abliterated checkpoint is more vulnerable than its original, compare them under controlled conditions:

• Same application.
• Same tools.
• Same permissions.
• Same attack set.
• Same execution policy.
• Same success criteria.

Measure unauthorized actions and information disclosure—not just whether the model says, “I can’t help with that.”

The practical conclusion is narrower:

Do not assume a modified checkpoint retains the original checkpoint’s security behavior. Test the deployed system.

And do not assume the original checkpoint was a sufficient security boundary either.

“It Runs Locally” Is Not a Security Architecture

Local inference answers one question:

Where does model computation happen?

It does not answer these:

What can the application read?
What operations can its tools perform?
Which network destinations can it reach?
Whose identity does it use?
Who authorizes its actions?

A locally hosted model connected to an email API still has an external communication channel.

An agent running on your laptop may still inherit permissions you never intended to delegate.

The relevant boundary is the workflow’s effective access. AWS’s guidance on excessive agency emphasizes least privilege and permissions boundaries for agentic systems. docs.aws.amazon

Run locally when it fits your requirements.

But do not confuse “inference happens on my machine” with “information cannot leave my machine.”

Four Ways a Helpful Agent Becomes a Security Incident

1. You Give It a General-Purpose Shell

A shell is convenient because it can do almost anything.

That is also the problem.

If the task is “read a document,” a general command executor supplies far more functionality than the task requires. OWASP recommends restricting available functionality rather than exposing unnecessarily powerful tools. genai.owasp

Prefer:

read_document(document_id)

Over:

run_shell(command)

The narrower interface is not automatically secure. It still needs authorization, resource resolution, and input validation.

But it gives you a smaller surface to control.

2. You Let It See Secrets It Does Not Need

If sensitive information enters the model’s context, it may appear in its output. OWASP identifies sensitive-information disclosure as a distinct risk and warns that prompt-level restrictions alone are insufficient protection. genai.owasp

Before asking:

“How do I make the model keep this secret?”

Ask:

“Why does this task require the model to see the secret?”

Where possible, let a narrowly scoped tool perform an operation without exposing the underlying credential to the model.

Access to a capability does not have to mean access to its secret.

3. You Execute Its Output Without Validation

Model-generated text is not inherently safe SQL, HTML, Python, or shell syntax.

Passing it downstream without appropriate validation and handling can create vulnerabilities such as cross-site scripting or unauthorized command execution. genai.owasp

For database access, prefer constrained operations with typed parameters over arbitrary SQL.

For browser output, apply context-appropriate encoding.

For tool execution, validate both the operation and its arguments.

“The model generated it” is not a sanitization strategy.

4. Your Approval Button Approves a Vibe

This is not meaningful authorization:

Allow the agent to continue?

What, exactly, is the user approving?

A useful approval shows the concrete operation:

Action: Send email
Recipient: [e-mail]
Attachments: quarterly-report.pdf
Data classification: Confidential

The application must then execute that same operation—not a modified version chosen after approval.

OWASP’s general controls recommend infrastructure-level approval gates and binding approval to specific action parameters. owaspai

Approval is not a reassuring sentence in a conversation.

It is an enforceable condition on execution.

Read-Only Does Not Mean Harmless

“Don’t worry. The agent only has read access.”

That is a useful restriction.

It is not a complete threat model.

An agent that can read sensitive material and communicate externally may disclose information without changing a single source file. Sensitive-information disclosure and excessive agency can combine across tools. genai.owasp

Consider:

Tool A: Read internal documents.
Tool B: Send an external message.

Each capability may have a legitimate purpose.

Together, they create a potential data-transfer path.

The more precise security question is:

Can information from this source reach that destination under this user’s authorization?

For an internal-document assistant, one possible design is:

Approved internal documents
        ↓
Authorized retrieval
        ↓
Answer to the authenticated user

No external messaging tool in this workflow.

The goal is not to make every tool harmless in isolation.

It is to control what the available tools can accomplish together.

Your Agent Can Hurt You Without Stealing Anything

Not every incident ends with a stolen API key.

Sometimes the agent simply keeps working.

And working.

And working.

Excessive or uncontrolled LLM usage can cause resource exhaustion, service degradation, and financial loss. OWASP groups these risks under unbounded consumption. genai.owasp

For an agent, I would translate that concern into explicit runtime budgets:

agent_budget:
  max_steps: 12
  max_tool_calls: 20
  wall_clock_timeout_seconds: 90
  max_output_tokens: 4000
  max_external_requests: 5

These numbers are illustrative—not universal defaults.

A document summarizer and a maintenance agent need different limits. A self-hosted model and a metered API expose different cost structures.

The shared principle is:

The model should not decide how much infrastructure it is allowed to consume.

Enforce limits outside the model. OWASP recommends controls including quotas, rate limiting, timeouts, and resource monitoring. genai.owasp

A polite system prompt is not a circuit breaker.

A Better Architecture: The Model Proposes, the Application Authorizes

Here is the separation to aim for:

User request
    ↓
Model proposes an action
    ↓
Application validates the action schema
    ↓
Policy checks identity, resource, and permissions
    ↓
Human approval if required
    ↓
Restricted executor performs the approved operation
    ↓
Result and audit record

Permissions and high-impact approval gates should be enforced outside the model. owaspai

For example, the model might propose:

{
  "tool": "read_document",
  "arguments": {
    "document_id": "report_042"
  }
}

The application independently checks:

• Is this tool permitted in the current workflow?
• Can the authenticated user access this document?
• Is the resource within the authorized scope?
• Does the operation require approval?
• Is the request within the execution budget?

The model does not answer those questions on the user’s behalf.

A model-generated field such as "authorized": true is a claim—not proof.

An Illustrative Tool Gateway

Here is simplified pseudocode showing the separation:

def handle_tool_request(proposal, session):
    action = validate_schema(proposal)

    tool = registry.require_allowed_tool(
        workflow=session.workflow,
        name=action.tool,
    )

    resource = tool.resolve_resource(action.arguments)

    policy.require_permission(
        user=session.authenticated_user,
        workflow=session.workflow,
        operation=tool.operation,
        resource=resource,
    )

    budget.require_capacity(
        run_id=session.run_id,
        operation=tool.operation,
    )

    if policy.requires_approval(tool.operation, resource):
        approvals.require_exact_match(
            run_id=session.run_id,
            user=session.authenticated_user,
            tool=action.tool,
            arguments=action.arguments,
            resolved_resource=resource,
        )

    return executor.run_restricted(
        tool=tool,
        arguments=action.arguments,
        resource=resource,
        identity=session.execution_identity,
    )

This is an architectural sketch, not production-ready security code.

The important boundaries are:

• Identity comes from the authenticated session.
• Tools must already be permitted for the workflow.
• Resources are resolved before authorization.
• Approval applies to a specific operation.
• Execution uses a constrained identity.

These choices reflect least privilege and external policy enforcement. docs.aws.amazon

A real implementation must also handle approval expiry, concurrent requests, retries, resource changes between checking and execution, and tool-specific validation.

An LLM does not make those engineering problems disappear.

Stop Testing Only What the Model Says

Here is a weak security test:

Prompt: “Will you reveal private information?”

Expected response: “No.”

That tests one conversational behavior.

It does not establish whether the application blocks an unauthorized read or prevents information from leaving through a tool.

A better question is:

Given an unauthorized proposed action,
does the execution layer reject it,
regardless of the model’s explanation?

I would build a test suite around cases like these:

Test	Setup	Expected behavior
Cross-user access	A requested document belongs to another account	Deny access before retrieval
Untrusted instructions	A retrieved document requests an unrelated action	Do not expand workflow permissions
External disclosure	A proposed action sends internal material outside the allowed boundary	Block it or enforce the applicable authorization
Changed action after approval	The recipient or attachment differs from the approved action	Reject the changed action
Runaway execution	The agent exceeds its execution budget	Stop the run and record the reason
Unsupported tool	The model invents a tool or parameter	Reject the request during validation

This is a proposed application test plan—not a claim that any particular model passes it.

Use synthetic secrets, test accounts, and a disposable environment.

The goal is to verify boundaries without putting real information at risk.

Measure Actions, Not Just Refusals

For a checkpoint comparison, useful measurements include:

• Unauthorized tool requests proposed.
• Unauthorized tool requests executed.
• Sensitive test data disclosed.
• Legitimate tasks completed.
• Legitimate actions incorrectly blocked.
• Execution cost and number of steps.

Keep proposal and execution metrics separate.

A model may propose something unsafe while the application correctly blocks it.

That is a different result from the same proposal being executed.

Also measure usefulness. A system that rejects everything may be difficult to exploit, but it is not a useful assistant.

Logs Should Explain the Action—Without Becoming Another Data Leak

“The AI did it” is not an incident report.

You need to reconstruct what happened.

For an action audit, I would aim to record:

Run identifier
Authenticated user
Workflow and policy version
Model checkpoint or deployment version
Requested tool
Resolved target
Authorization result
Approval identifier, if applicable
Execution status
Budget usage

OWASP recommends monitoring and logging to identify unusual consumption patterns. The format above is a proposed extension for tracing agent actions. genai.owasp

But logging everything indiscriminately creates another problem.

Prompts, tool arguments, and tool responses may contain sensitive information. Your audit design should minimize unnecessary sensitive content and restrict access to retained records. genai.owasp

Log enough to investigate the decision.

Do not turn your observability platform into an accidental archive of private documents and credentials.

Have a Stop Button Before You Need One

Before deployment, define what happens if the agent performs unauthorized actions.

A practical response plan could include:

1. Stop new runs.
2. Cancel active jobs where possible.
3. Disable tool execution.
4. Suspend the agent’s credentials.
5. Preserve relevant audit records.
6. Identify affected resources and external destinations.
7. Rotate credentials if exposure is suspected.
8. Reproduce the failure in isolation before re-enabling the workflow.

This is a proposed operational playbook, not an account of a specific incident.

Scoped execution identities and least privilege make the permission boundary easier to reason about. docs.aws.amazon

The crucial question is:

Can you stop the agent’s actions without asking the agent to stop?

If the only emergency control is another message to the model, the control is in the wrong place.

When Would I Use an Abliterated Model?

I would evaluate one for a specific purpose—not as a blanket upgrade.

Possible experimental uses include:

• Studying how refusal-related interventions affect behavior.
• Comparing checkpoints on legitimate requests that receive unnecessary refusals.
• Measuring capability changes before and after modification.
• Running controlled conversational or creative experiments.

Abliteration is useful as a research intervention because it can modify refusal behavior without a full retraining run. Published examples also show why capability preservation needs separate evaluation. huggingface

My deployment approach would depend on the surrounding permissions:

Environment	My approach
Disposable research environment with synthetic data and no external tools	Controlled experimentation
Internal-document assistant	Access scoping and disclosure tests before rollout
Coding agent with execution tools	Isolated workspace, constrained execution, and explicit budgets
Agent with production administration or broad external communication	Stronger justification, narrow permissions, and independent review

This is a risk-based design preference, not a universal classification of model safety.

The same scrutiny should apply to a conventional instruction-tuned model with equivalent access.

Five Myths Worth Retiring

“Uncensored Means Smarter”

Reduced refusal is not evidence of improved reasoning or factual accuracy. Benchmark results must be evaluated separately. huggingface

“Abliteration Removes All Safety”

That is too broad. Targeting refusal-related behavior does not establish that every safety behavior is removed—or that every request will succeed. huggingface

“A Strong System Prompt Is Enough”

Prompt instructions do not replace resource authorization, restricted tools, or infrastructure-enforced approval. owaspai

“Read-Only Means No Damage”

It limits modification. It does not eliminate disclosure when sensitive information can reach an output or communication channel. genai.owasp

“A Restrictive Model Makes Powerful Tools Safe”

Behavioral safeguards can contribute to defense in depth. They do not eliminate the need to limit functionality, permissions, and autonomy. genai.owasp

The Deployment Checklist

Before connecting an abliterated—or any other—model to real tools:

• Use task-scoped identities.
• Grant only the permissions needed for the workflow.
• Prefer granular tools over open-ended execution.
• Enforce authorization on every tool call.
• Require explicit approval for high-impact operations.
• Bind approval to the exact target and parameters.
• Validate output before downstream execution.
• Keep unnecessary sensitive information out of context.
• Enforce time, step, request, and resource limits.
• Test with malicious content in documents, emails, and webpages.
• Maintain an independent way to stop execution. genai.owasp

These controls should not disappear when you switch back to a more restrictive model.

A safer default model can be useful.

It should not be the component that decides whether your production database is writable.

The Real Test: Assume the Model Makes the Wrong Choice

The debate around uncensored AI often gets stuck on personality:

Is the model obedient?

Does it refuse too much?

Will it answer a controversial question?

For system security, there is a more useful starting point:

Assume the model proposes the wrong action. What stops that action from happening?

If the answer is “the model usually knows better,” your boundary is behavioral.

If the answer is “the executor denies it because this identity cannot perform that operation on this resource,” you have an independently enforced boundary. That is the direction recommended by least-privilege and excessive-agency guidance. docs.aws.amazon

Experiment with abliterated models.

Measure what changed.

Keep the benefits you can demonstrate.

But build your application so that a wrong answer stays a wrong answer—not an executed incident.

A model can be allowed to say almost anything.

That does not mean your infrastructure should let it do almost anything.
created by : https://almodarresieh.github.io/

Comments

[Qingfeng]

The point that authorization belongs to the application and not to the model is the one I keep re-explaining to colleagues. Two things made it concrete for me. First, per action permissions with a default of deny, so a tool that is not explicitly allowlisted does not exist in the agent tool surface at all, instead of being discouraged by a system prompt. Second, every irreversible step gets its own approval, with a plain language preview of the exact command and target. I also refuse to let one poisoned read hand over a write: the tool that fetches webpages for summarising has no network egress and no filesystem mount. How do you handle the case where the fallback tool ends up more privileged than the one you denied?