4P3X Guardian AI™

The problem, without the science fiction

What does “rogue AI agent” actually mean?

A rogue or unsafe agent may simply be an agent whose behaviour has moved outside authorised human intent.

It does not have to become sentient, evil or independently decide to attack humanity. A dangerous outcome can begin with an ordinary error, malicious input or more permission than the task requires.

That can happen because the agent is:

• Prompt-injected or manipulated by malicious data.
• Compromised, or operating with excessive permissions.
• Acting on stale instructions or using stolen or inappropriate credentials.
• Misunderstanding human intent.
• Following a malicious instruction embedded inside an email, file, website, memory or tool response.
• Delegating authority incorrectly.
• Combining several individually harmless capabilities into a dangerous capability.
• Suffering long-horizon goal drift: gradually moving away from the authorised objective.
• Attempting to bypass a refusal through another tool or route.
• Communicating protected information to an unauthorised destination.
• Acting from corrupted memory.
• Exploiting an approval interface or misclassifying an action.
• Hallucinating that an action succeeded.
• Concealing or deleting evidence of its behaviour.
• Or simply being confidently wrong.

Rogue does not have to mean evil.
It can mean: wrong + powerful + authorised to do too much.

This is why 4P3X Guardian AI™ is being designed around controlling authority and real-world effects, not merely trying to make an AI model produce nicer answers.

The fundamental Guardian question

If an AI agent does something wrong, how much power does it actually have?

• Can it access the system?
• Can it use the credential?
• Can it contact that destination?
• Can it spend the money?
• Can it modify the file?
• Can it deploy the software?
• Can it operate the machine?
• Can it delete the evidence?
• Can it continue after a human says STOP?
• Can it find another route after Guardian denies the first one?

These are authority questions.

4P3X Guardian AI™ is being designed to answer them independently of the reasoning model. The aim is a separate, enforceable boundary around consequential action.

Alignment is not the same as control

Good intentions are not a security boundary.

AI alignment attempts to make models produce desirable behaviour. That remains important. But Guardian works from a stronger assumption: alignment may sometimes fail.

A model may misunderstand. A prompt injection may succeed. A compromised agent may behave strategically. A tool may return malicious information. An otherwise capable model may make a simple mistake.

Guardian is being developed as another layer around the intelligence itself.

• Intelligence ≠ authority.
• Knowledge ≠ permission.
• Access ≠ authorisation.
• Authentication ≠ authorisation.
• Request ≠ execution.
• Execution ≠ verified success.
• Model claim ≠ system truth.

These are architectural distinctions. They do not establish that every production route is already protected or that every attack can be prevented.

The Guardian principle

Intelligence can propose. It cannot grant itself authority.

AI intelligence proposes.
Guardian constrains.
Trusted systems execute.
Independent evidence proves.
Humans retain consequential authority.

The five roles below describe the intended separation of responsibilities. The development evidence and remaining promotion gates are set out later on this page.

1. AI intelligence proposes

   An AI agent can analyse, plan, reason and propose an action. It does not create its own authority merely because it believes the action is useful.

2. Guardian constrains

   The intended Guardian boundary independently checks:

   • Identity and intent.
   • Policy, capability and target.
   • Permissions and credential scope.
   • Data classification and approval state.
   • Environment and risk.
   • Revocation and current system state.

   The model may propose. The policy engine decides.

3. Trusted systems execute

   Protected actions must pass through approved execution boundaries. The reasoning model should not itself be the final execution authority.

4. Independent evidence proves

   Guardian's execution-ledger architecture is designed to record what the trusted execution system actually did.

   An agent saying “I sent it”, “I deleted it”, “I deployed it”, “I paid it” or “I changed it” is not enough. The actual system result must provide the evidence.

   No receipt. No verified completion.

5. Humans retain consequential authority

   High-impact, irreversible, dangerous or rights-affecting decisions remain subject to appropriate human authority and governance.

Powerful reasoning, bounded authority

Why build Guardian toward frontier capability?

Long-term research objective

The long-term objective is frontier-grade defensive intelligence. Guardian is not being presented as an already completed frontier foundation model.

As AI agents become more capable, attacks against AI systems can become more complex. A future Guardian intelligence layer may need to detect:

• Subtle goal drift and unusual action sequences.
• Indirect prompt injection and cross-agent manipulation.
• Capability composition: separate permissions combining into greater power.
• Hidden data exfiltration and credential reconstruction.
• Deceptive behaviour and approval manipulation.
• Semantic laundering: disguising a sensitive action or destination as something harmless.
• Unusual tool combinations and long-horizon behaviour.
• Monitoring evasion.
• Attempts to find alternative routes after denial.
• Previously unseen combinations of known attacks.

A simple static filter cannot understand every novel combination. This is why powerful reasoning is part of Guardian's research direction.

Frontier intelligence does not mean frontier authority.

The Guardian intelligence model may detect, analyse, classify and recommend. It must not become the sole security boundary.

In the intended architecture, deterministic security controls remain responsible for permissions, credentials, revocation, execution and protected-system access. This creates defence in depth: different controls have distinct responsibilities, so safety does not depend on one model being right.

Who watches the Guardian?

Guardian must not become the thing we are trying to prevent.

Creating one extremely powerful AI and giving it absolute authority over every other AI would simply move the trust problem.

4P3X Guardian AI™ is therefore designed so that Guardian itself is constrained. Its architecture calls for:

• Deterministic policy enforcement.
• Least privilege and scoped capability leases.
• Human authority.
• Independent execution records.
• Revocation and emergency stop.
• Protected evidence.
• Separation of duties.
• Independent verification.
• Auditability.
• Sandboxing.
• Adversarial testing.

No AI, including Guardian, should be the sole authority on whether its own actions were safe.

The intelligence that identifies a risk must not be allowed to silently rewrite policy, expand its own permissions or certify its own execution. Those boundaries need evidence and testing of their own.

Programme context

Building Defensive Frontier Intelligence

4P3X Guardian AI™ is an active frontier-model development programme focused on advanced reasoning, defensive intelligence, autonomous-agent governance, independent verification, resilient operation and the safe control of increasingly capable AI systems.

Frontier-grade defensive intelligence is the long-term objective. The current evidence remains bounded to governed architecture, sandbox prototypes and recorded testing. The development timeline, case study and research direction below remain part of the programme record.

The Guardian control plane

A request must earn its way to execution.

This is the intended control architecture: an agent proposes an action, while separate controls check its authority, govern execution and establish what actually happened.

Architecture flow, not a live network display. These stages describe the control design; they do not claim production enforcement across every 4P3X system.

1. Human / authorised system intent

   Start with a legitimate objective from an identified human or authorised system.

2. Identity

   Establish who or what is requesting the action, including the workload and any delegated actor.

3. Intent contract

   Make the objective, permitted effects, limits and completion conditions explicit.

4. Capability lease

   Bind temporary authority to the task, tool, target and permitted scope.

5. Guardian policy decision

   Check the request against current policy, authority, approval, environment and revocation state.

   • Allow
   • Deny
   • Restrict
   • Hold for approval
   • Sandbox only

   Only an allowed action, or an action meeting its explicit restrictions, may proceed. A denied or held action has no execution authority; sandbox authority cannot authorise a live target.

6. Credential broker

   Provide only the credential access permitted for the approved action and service.

7. Execution gateway

   Re-check the authorised action immediately before it reaches a protected execution boundary.

8. Protected tool / service / machine

   Perform only the operation that the execution boundary permits.

9. Independent execution receipt

   Record the execution system's result independently of the agent's account.

10. Outcome verification

    Check whether the observed result satisfies the authorised objective. An attempted action is not necessarily a successful one.

11. Tamper-evident evidence

    Protect records and integrity information from ordinary agent modification.

12. Audit / learning / response

    Use retained evidence for review, corrective engineering and governed response. Learning does not automatically widen permission.

The model may propose. The policy engine decides.

Capability leases

Permission should expire.

An AI agent should not receive permanent authority simply because a user once approved a task. Guardian uses the concept of temporary Capability Leases.

Authority should be temporary, specific, revocable and no broader than necessary.

Complete mediation

No authorised action envelope. No execution.

Protected actions should pass through Guardian immediately before execution. The security rule applies to the effect being attempted, not merely the name of the tool used.

An action envelope is the bounded description of what was authorised: who may act, on which target, with which parameters and under which conditions. An AI agent should not be able to:

• Bypass Guardian through a different connector.
• Use a browser instead of an API to evade policy.
• Switch tools after a denial.
• Reuse stale approval.
• Widen parameters after approval.
• Change the target after approval.
• Use a credential outside its intended service.
• Interpret successful login as permission.
• Directly contact protected infrastructure.

A denied action must not become an allowed action just because the agent found another door.

Authentication does not create authority.

Independent action truth

The agent does not get to write its own police report.

Language models can explain what they think happened. That does not make the explanation authoritative.

Guardian's design separates these two accounts. Every consequential action should produce an independent record with appropriate information, such as:

• Actor / workload identity.
• Requested operation.
• Target.
• Parameters.
• Policy decision.
• Capability authority.
• Approval state.
• Credential class.
• Timestamp.
• Execution result.
• Affected resource.
• Verification evidence.
• Final outcome.

No receipt. No verified completion.

The agent is not the authority on what the agent did.

Human stop must mean stop

Stop is a security command, not a polite suggestion.

If an authorised human rejects, revokes or stops an agent action, Guardian should terminate the relevant machine authority.

Stopping must propagate into:

• Capability leases.
• Delegated authority.
• Credentials.
• Queued work.
• Pending actions.
• Execution gateways.
• Child agents.
• Sessions.
• Delayed callbacks, where technically possible.

The agent continuing to reason does not mean it continues to possess authority. Revocation must be enforced by the surrounding systems, not depend on the agent choosing to obey another message.

A human stop decision must retire machine authority, not merely add another message to the conversation.

This is a control requirement. Stronger revocation and quiescence testing remains part of the gates for broader live authority.

Prompt propagation defence

The attack may arrive inside ordinary data.

A malicious instruction does not need to arrive as a direct chat message. It may be hidden in material the agent was asked to read.

• Email.
• Documents.
• Websites.
• Code.
• Comments.
• PDFs.
• Tool output.
• Retrieved knowledge.
• Memory.
• Messages from another agent.

Guardian's intended architecture treats external information as data with provenance: where it came from and why it is being used. Reading an instruction inside that data must not turn it into an authorised command.

Data may inform an agent. Data must not silently grant an agent permission.

Composite capabilities and transitive authority

Five harmless tools can become one dangerous capability.

Individual permissions may appear safe in isolation. Combined, they can create an effect that no individual permission was intended to authorise.

These are high-level threat illustrations. Guardian needs to analyse composite and transitive capabilities, not merely inspect tools individually. That deeper analysis remains part of the development and assurance work.

Security must analyse what capabilities can become when combined.

Data egress control

Not everything an agent can read should be something it can send.

Source-to-sink control means checking both where information comes from and where it is going. Permission to read is not permission to transmit.

Source

Where did this information come from?

Classification

How sensitive or trusted is it?

Authority

Why is the agent allowed to use it?

Sink

Where is the information going?

Purpose

Why does it need to leave?

Guardian should evaluate potential destinations such as:

• Another internal service.
• An external API.
• Email.
• Messaging.
• A browser.
• Memory.
• A model-training dataset.
• Public output.
• Another agent.
• A physical device.

The ability to read information must never automatically grant permission to publish or transmit it.

Protected evidence

An attacker must not be able to delete the CCTV footage of its own attack.

That is an analogy for evidence protection, not a claim about camera surveillance. Guardian evidence must exist outside the ordinary monitored agent's ability to rewrite or destroy it.

The evidence design should include:

• Append-only or tamper-evident records.
• Integrity checks.
• Protected storage.
• Sequence tracking.
• Evidence-object digests.
• Detection of deletion or alteration attempts.
• Independent timestamps where appropriate.
• Policy / version history.
• Retained failure evidence.

Tamper-evident means alterations can be detected under the system's stated assumptions; it does not mean evidence is magically indestructible.

Failed tests are evidence too.

Historical failures must not be silently deleted or rewritten after an architecture is fixed. Later success belongs beside the original evidence.

Safe hold

When the system is uncertain, pause authority before guessing.

Where important evidence conflicts, Guardian should be capable of entering a safe hold state. A hold creates space to verify the situation before granting consequential authority.

A safe hold may:

• Suspend actuation.
• Pause consequential writes.
• Preserve sensing where safe.
• Preserve evidence.
• Request human review.
• Re-check current authority.
• Verify the environment.
• Resume only through a valid controlled route.

1. Uncertainty
2. Safe hold
3. Verify
4. Authorise or deny
5. Controlled resume, only if authorised

Least agency necessary

Don't deploy an autonomous agent when a read-only query will do.

Guardian should control not only what an agent may do, but how much agency the task actually requires.

1. Read / answer only
2. Retrieval
3. Recommendation
4. Draft action
5. Reversible action
6. Multi-step action
7. Autonomous action
8. Physical / safety-critical action

The system should choose the lowest level of agency capable of completing the legitimate objective. These levels describe possible authority requirements; they are not a list of approved live Guardian capabilities.

Greater agency requires stronger evidence and stronger control.

More autonomy creates more possible failure paths. The scope of machine authority should grow only when the task needs it and the evidence supports it.

Critical infrastructure

Reachable does not mean authorised.

Future AI agents may interact with systems whose failures affect people directly. Guardian's intended architecture treats these as protected sinks.

• Energy infrastructure.
• Communications.
• Industrial systems.
• Transport.
• Healthcare.
• Robotics.
• Drones.
• Buildings.
• Community infrastructure.
• Financial systems.
• Safety systems.

A generic agent should never gain authority over critical infrastructure merely because:

• An endpoint exists.
• Credentials work.
• A connector is installed.
• The model identifies the target.
• A previous action succeeded.
• The user once discussed the system.
• A sandbox configuration resembles production.

Environment + identity + target + operation + purpose + authority + current policy

All must be valid before protected execution is considered.

This describes an intended protection boundary. It does not establish protection of live critical infrastructure or permission to connect a prototype to it.

If Guardian itself fails

Fail closed.

Security infrastructure is not magically immune to failure. Guardian must define what happens when a decision cannot be trusted.

That includes situations where:

• The policy service is unavailable.
• The credential broker fails.
• Verification is unavailable.
• Evidence storage becomes unavailable.
• Identity cannot be established.
• The environment cannot be verified.
• Revocation state is unknown.
• Conflicting authority is detected.

For high-impact actions, unknown must not silently become allow. A failure must not grant new authority or let an unverified request slip through the execution boundary.

Unknown authority ≠ permission.

Recorded development evidence

Current development status

4P3X Guardian AI™ currently has governed architecture, runnable sandbox prototypes and recorded adversarial testing evidence. These are foundations for further engineering and assurance, not a claim of complete production protection.

Established architecture components

The checkmarks identify components in the architecture and sandbox programme. They do not certify production enforcement across every 4P3X system.

• ✓ Threat Model & Abuse Case Catalogue
• ✓ Independent Action Event / Execution Ledger architecture
• ✓ Deterministic Policy Decision Point
• ✓ Capability Lease Engine
• ✓ Synthetic Credential Broker architecture
• ✓ Execution Gateway architecture
• ✓ Independent Verification / Outcome Resolver architecture
• ✓ Tamper-Evident Evidence architecture
• ✓ Source–Sink Information-Flow controls
• ✓ Adversarial Test Harness architecture
• ✓ Process-Isolated Sandbox architecture
• ✓ Shadow Mode architecture

Recorded sandbox results

Each row belongs to its own recorded test family or release scope. These results are deliberately not added into one giant score. Passing these tests does not establish production certification, universal attack coverage or permission to deploy autonomous actions.

Evidence boundary: these are recorded development results reported in this public summary. Publishing them does not constitute a fresh test run or independent certification. The earlier cube planning benchmark remains a separate case study; it is not an agent-security certification.

Adversarial testing and retained history

We are not hiding the red tests.

Guardian development deliberately uses adversarial testing to expose weaknesses before stronger authority is granted. A later success does not erase an earlier failure.

Find failure. Understand failure. Fix the architecture. Retest. Keep the evidence.

Promotion requires evidence

The next door stays locked until the evidence earns the key.

v0.4 — LOCKED

4P3X Guardian AI™ has deliberately not been promoted into broader consequential live authority simply because its sandbox testing looks promising.

Before broader autonomous/live capability is reconsidered, current Guardian development requires stronger controls and evidence including:

• Human Revocation & Persistence Breaker.
• Prompt Propagation Firewall.
• Composite Capability / Transitive Authority Graph.
• Fragmented-secret reconstruction detection.
• Privilege-enumeration detection.
• Independent anti-forensics evidence plane.
• Cross-connector invoker attribution.
• Sink-specific authority.
• Critical-infrastructure containment tests.
• Sandbox-to-live route testing.
• Direct and transitive egress testing.
• Revocation and quiescence testing.
• Additional AGSEC adversarial tests.

These are promotion requirements and next-stage assurance work. A reference to a control in the architecture is not proof that its complete production implementation has passed those gates.

Passing a test does not create authority.
Evidence earns the next test.

The bigger mission

Protect people first. Then systems. Then continuity.

Guardian exists to enable powerful AI safely, not to suppress useful AI.

The intended architecture should support useful autonomy, accessibility, research, engineering, education, automation, robotics, scientific work, industrial systems, local and offline intelligence, and connected infrastructure—while controlling how intelligence obtains and uses real-world authority.

The goal is not to make AI powerless.
The goal is to make AI powerful without making power unaccountable.

Human dignity, freedom and agency take priority over system self-preservation. Protecting a system must never become a justification for overriding the people it is meant to serve.

Four questions that authority must answer

The four Guardian questions

1. 1 — Who?

   Who or what is requesting the action?

2. 2 — What authority?

   Exactly what is it permitted to do right now?

3. 3 — What actually happened?

   What does independent execution evidence show?

4. 4 — Who can stop it?

   Can authorised humans and systems reliably revoke the capability?

If a powerful autonomous system cannot answer all four questions reliably, it should not receive unrestricted consequential authority.

Public Guardian manifesto

4P3X Guardian AI™

Powered by 4P3X Intelligent AI™
Created by Kyzel Kreates™