Home / AI architecture
MALEVOLENTAGENT
AI agents: AI architecture
AI agents: AI architecture. Explore a technically serious editorial project about AI systems, assumptions and security research. This guide makes the question, evidence and next steps easier to follow while keeping the scope of the page clear. Use the topic links to choose the next explanation or open a focused enquiry.
On this page
Map the system before judging it
AI agents are easier to assess when the surrounding system is mapped before its behaviour is judged. Identify the model, the information it receives, the tools it can call and the state it can retain. Separate producing an answer from changing an external system. An architecture description should expose those distinctions without treating a successful demonstration as a security certificate. Begin with the job the system is meant to do and the boundaries it must respect.
For a closer look at how technical claims should be examined, continue to the technical stories guide. It connects architecture questions with the evidence, limitations and implementation context that a useful account of an AI system should make visible.
Map AI agents as a sequence of inputs, decisions and permitted actions. A simple diagram should let a reader follow how one request reaches an external tool without assuming that every component shares the same authority.
Inputs and trust boundaries
Inputs do not all deserve the same trust. A user’s instruction, retrieved document and external tool response can contain different kinds of material. Ask how the system distinguishes reference content from authority to act. The answer needs more than a label in a prompt. Follow the dangerous assumptions guide for the related prompt-injection question. An architectural review should identify what could influence a decision and where that influence is meant to stop.
A review of AI agents should identify which material is instruction and which is reference data. Record how that distinction is enforced, what evidence supports it and where the explanation relies only on a written rule.
Continue with Research dossiers.
Tools and permissions
A tool’s capabilities and the agent’s permissions are separate questions. Describe what each tool can read, write or trigger, then identify the conditions under which the agent can use it. Narrow permissions can reduce exposure, but their actual enforcement needs evidence. A written rule does not by itself establish a technical boundary. This guide is conceptual and defensive; it does not supply exploit instructions or claim that a particular deployment has passed a security assessment.
Permissions for AI agents need an explicit task context. Ask why a tool requires a particular read or write capability, and whether the intended job can be completed with a narrower boundary.
Memory and state
Memory and state introduce continuity, but they also introduce decisions about retention. Ask what is stored, who can read it and how a later task can use it. Separate temporary context from persistent records. A useful design explanation identifies both the purpose and the limits of each kind of state. Do not assume that a folder name or a memory feature makes information private. Access and retention need to be evaluated in their actual environment.
State retained by AI agents should have a purpose and an access explanation. Distinguish information useful to a later task from information that would unnecessarily carry a private record into unrelated work.
Observability and failure
Observability helps an investigator understand what occurred. A record should connect a selected input, decision and permitted action without unnecessarily exposing sensitive material. Define the conditions that stop a task and how a failure becomes visible. Logging everything is not automatically a good answer; useful evidence needs an appropriate scope. A health check may show that a system is running while saying little about whether a particular action respected its intended boundary.
A useful trace connects an allowed action with the evidence supporting it. Avoid retaining everything merely because logs are available; selected records should explain the decision without unnecessarily exposing sensitive inputs or account material.
Continue with Research dossiers.
Questions for a technical review
Review the architecture using a small set of defensive questions. What can influence the agent? What can it change? Which consequential decisions require another authority? What evidence demonstrates the boundary, and what remains untested? A diagram becomes useful when those questions can be traced through it. Avoid treating a familiar component or publisher name as a substitute for that evidence. The scope of a test should remain attached to the result it supports.
Use the checklist to separate a demonstrated boundary from a proposed one. Record the named environment and conditions for the result, so readers can understand what changes would require a fresh assessment.
Related technical reading
The research dossier guide turns an architectural question into a structured investigation. Technical stories can then explain a particular interaction without pretending to be an exhaustive audit. Read the editorial approach for how sources, versions and uncertainty are handled. These pages describe an editorial research direction, not a collection of fabricated completed investigations. Suggest a public technical question through the contact page; do not submit private infrastructure records or credentials.
Questions before the next step
Does a technical guide certify my system?
No. A conceptual explanation or a bounded research account is not a security assessment of your deployment. A finding depends on its version, inputs, environment and stated checks. Preserve those limits when interpreting it. The research guides help frame questions, while any real assessment needs its own appropriate authority, scope and evidence.
Can I upload code for analysis here?
No. The scanner is a planned, unavailable project, and these pages provide no upload or live-analysis workflow. Do not email proprietary source code, credentials or confidential incident material. Public technical questions and source suggestions are suitable editorial inputs. A future product would require a separate description of capabilities and data-handling terms.
How do I propose a correction?
Identify the page, exact claim and public source that supports the correction. Explain whether the issue concerns a version, an observation, an interpretation or a missing boundary. A narrow, checkable question is more useful than an unsupported broad accusation. The contact route is editorial and does not promise confidential incident response or a contracted investigation.
Technical reference
OWASP GenAI Security: prompt injection risk. The reference supplies context, not a security assessment of your deployment.
Start with a clear question
Use the MalevolentAgent contact page for a public technical question, source suggestion or editorial correction. The email button opens your own mail application; review the message before sending and keep credentials or private records out of an initial enquiry.