Defensive Security and Capability-Boundary Guide for OntologicalMachine.com

Full report

On this page

A. Scope and Threat Model

The deployment of autonomous multi-agent systems and Large Language Models (LLMs) fundamentally alters traditional application security perimeters. OntologicalMachine.com operates on a strict paradigm: internal probabilistic reasoning must be cryptographically and physically isolated from the authority to access files, networks, credentials, processes, databases, or external services. This architecture mandates a Zero Trust Architecture (ZTA) wherein no implicit trust is granted to any agent based on its internal state, origin, or prompt1. Instead, all external actions must pass through deterministic capability boundaries, evaluated by an externalized policy decision point (PDP) such as Cedar, Cerbos, or Open Policy Agent (OPA)3. The integration of non-deterministic models requires shifting defenses from static network perimeters to discrete resource transactions2. By decoupling intent formulation from execution authorization, the system ensures that even a completely compromised reasoning engine cannot perform unauthorized actions3. The threat model below evaluates the distinct attack surfaces introduced by agentic workflows, aligning with the OWASP Top 10 for LLM Applications and the Agentic Security Initiative6.

The analysis indicates a cascading relationship among these vulnerabilities. A successful prompt injection often serves as the initial vector, forcing the model into a confused deputy state. Without strict capability boundaries, this deputy exploits excessive permissions to achieve hidden network access or secret leakage. Consequently, defending the capability boundary rather than attempting to filter the non-deterministic reasoning engine represents the only mathematically sound defensive posture.

B. English Guide: Capability Boundaries in Agentic Systems

The implementation of generative AI within software engineering workflows necessitates a paradigm shift in authorization architectures. Traditional Role-Based Access Control (RBAC) proves insufficient for autonomous agents because the host application cannot inherently trust the control flow generated by an LLM. OntologicalMachine.com resolves this through the enforcement of strict capability boundaries, treating the LLM solely as an untrusted, isolated reasoning engine. The foundational principle of this architecture relies on the total decoupling of the agent's intent from the execution of the action. When an agent determines a file must be read or an external API must be called, it is physically and cryptographically prevented from invoking the host system directly. Instead, the agent is restricted to generating an intent proposal3. This proposal is subsequently intercepted by an isolated gateway that maps the request to a deterministic execution contract. This mechanism serves as a direct, structural mitigation for prompt injection and excessive agency8. While an attacker may successfully inject a prompt that convinces the model to formulate a malicious command, the architecture prevents the model from possessing the authority to execute it10. To enforce authorization deterministically without introducing coupling, OntologicalMachine.com employs externalized Policy Decision Points (PDPs). Engines such as Cedar, Open Policy Agent (OPA), and Cerbos utilize specialized, human-readable policy languages to evaluate multi-dimensional access requests in sub-millisecond timeframes20. When the agent submits an intent proposal, the gateway constructs a formal evaluation request containing the Principal (the agent's verified cryptographic identity), the Action (the requested tool), the Resource (the target data), and the Context (temporal signals and user trust scores). The PDP processes this tuple and returns a strict, binary authorization decision5. Because the PDP operates entirely on static policies defined out-of-band via GitOps, the LLM exerts zero influence over the evaluation logic. This configuration enforces an intent-based pipeline where multi-agent conflicts are resolved centrally, ensuring execution remains strictly bounded3. For workflows requiring dynamic code generation and execution, operating system-level process isolation is a non-negotiable requirement. Relying solely on standard containerization is insufficient due to the persistence of shared kernel vulnerabilities. Deep defense requires hypervisor-level isolation or advanced kernel security modules. The integration of Wasmtime allows untrusted code to run within a WebAssembly sandbox, guaranteeing memory-safe execution and near-native performance13. Furthermore, technologies such as Linux Landlock empower unprivileged processes to dynamically restrict their own access rights, dropping capabilities permanently before invoking untrusted parsers or handling external inputs14.

C. Simplified Chinese Guide: 自主系统中的能力边界 (Simplified Chinese)

在软件工程工作流中引入生成式人工智能，必然要求授权架构发生根本性的范式转变。传统的基于角色的访问控制（RBAC）对于自主智能体（Agent）来说已被证明是不够的，因为主机应用程序本质上无法信任由大语言模型（LLM）生成的控制流。OntologicalMachine.com 通过强制执行严格的能力边界解决了这一问题，将 LLM 纯粹视为一个不可信的、被隔离的推理引擎。 该架构的基本原则依赖于将智能体的意图与动作的执行完全解耦。当智能体决定必须读取文件或调用外部 API 时，它在物理和密码学层面被阻止直接调用主机系统。相反，智能体仅限于生成一个“意图提案（Intent Proposal）”3。随后，该提案会被一个隔离的网关拦截，网关将请求映射到确定性的执行契约中。这种机制直接从结构上缓解了提示词注入和过度代理的威胁8。尽管攻击者可能成功注入提示词并说服模型构思出恶意命令，但该架构完全剥夺了模型执行该命令的权限10。 为了在不引入耦合的情况下确定性地强制执行授权，OntologicalMachine.com 采用了外部化的策略决策点（PDP）。Cedar、Open Policy Agent (OPA) 和 Cerbos 等引擎利用专用的人类可读策略语言，在亚毫秒级的时间框架内评估多维度的访问请求20。当智能体提交意图提案时，网关会构建一个正式的评估请求，其中包含主体（智能体经验证的密码学身份）、操作（请求的工具）、资源（目标数据）以及上下文（时间信号和用户信任分数）。PDP 处理该元组并返回严格的二元授权决策5。由于 PDP 完全基于通过 GitOps 在带外定义的静态策略运行，LLM 对评估逻辑没有任何影响力。此配置强制执行了基于意图的流水线，在该流水线中，多智能体冲突被集中解决，确保执行受到严格的边界限制3。 对于需要动态生成和执行代码的工作流，操作系统级别的进程隔离是不可协商的要求。由于共享内核漏洞的持续存在，仅依赖标准容器化是不够的。深度防御需要基于大内层（Hypervisor）的隔离或高级内核安全模块。Wasmtime 的集成允许不可信代码在 WebAssembly 沙盒内运行，保证了内存安全的执行和接近原生的性能13。此外，Linux Landlock 等技术赋予非特权进程动态限制自身访问权限的能力，在调用不可信解析器或处理外部输入之前永久丢弃多余权限14。

D. Defensive Code Examples

The following section details eighteen exhaustive defensive patterns implemented in Python, the primary orchestration language for modern AI architectures. Each example contains setup instructions, defensive source code, verification tests, expected operational denials, and a critical analysis of remaining limitations.

1. Capability Object or Token

Capabilities encapsulate authority cryptographically, ensuring that an agent cannot forge permission to execute an action. Command Setup:pip install pyjwt cryptography Defensive Source Code:

Python import hmac import hashlib import json import time import base64

class CapabilityToken: def \_\_init\_\_(self, secret\_key: bytes): self.secret \= secret\_key

def issue\_token(self, agent\_id: str, allowed\_action: str) \-\> str: payload \= json.dumps({ "sub": agent\_id, "act": allowed\_action, "exp": int(time.time()) \+ 300 }).encode() b64\_payload \= base64.urlsafe\_b64encode(payload).decode() signature \= hmac.new(self.secret, b64\_payload.encode(), hashlib.sha256).hexdigest() return f"{b64\_payload}.{signature}"

def verify\_token(self, token: str, required\_action: str) \-\> bool: try: b64\_payload, signature \= token.split('.') expected\_sig \= hmac.new(self.secret, b64\_payload.encode(), hashlib.sha256).hexdigest() if not hmac.compare\_digest(expected\_sig, signature): return False data \= json.loads(base64.urlsafe\_b64decode(b64\_payload).decode()) if data\["exp"\] \< time.time() or data\["act"\] \!= required\_action: return False return True except Exception: return False

cap \= CapabilityToken(b"super-secret-key-256") token \= cap.issue\_token("agent-007", "read\_db")

Tests and Expected Denials:

Python print("Valid token access:", cap.verify\_token(token, "read\_db")) \# Output: Valid token access: True

print("Tampered token access:", cap.verify\_token(token, "write\_db")) \# Output: Tampered token access: False (Expected Denial)

Remaining Limitations: Token revocation requires an external distributed cache (such as Redis) to track blacklisted signatures before natural expiration occurs. Stateless verification alone cannot preemptively invalidate a compromised but unexpired token.

2. Default-Deny Tool Registry

Tools must be explicitly registered within the system architecture; all unmapped requests from the LLM are instantly rejected. Command Setup: Standard library only. Defensive Source Code:

Python from typing import Callable, Dict

class ToolRegistry: def \_\_init\_\_(self): self.\_tools: Dict\[str, Callable\] \= {}

def register(self, name: str) \-\> Callable: def decorator(func: Callable) \-\> Callable: self.\_tools\[name\] \= func return func return decorator

def execute(self, name: str, \\kwargs) \-\> str: if name not in self.\_tools: return f"DENY: Tool '{name}' is not authorized or does not exist." try: return self.\_tools\name\ except Exception as e: return f"ERROR: Execution failed securely \- {str(e)}"

registry \= ToolRegistry()

@registry.register("get\_time") def get\_time(): return "12:00 UTC"

Tests and Expected Denials:

Python print(registry.execute("get\_time")) \# Output: 12:00 UTC

print(registry.execute("format\_drive")) \# Output: DENY: Tool 'format\_drive' is not authorized or does not exist. (Expected Denial)

Remaining Limitations: The registry enforces availability but does not inspect argument integrity. Argument schema validation must occur within the tool itself or via a middleware parsing layer.

3. Explicit Operation Allowlist

Input must match a predefined set of strictly approved string constants, avoiding regular expression bypasses. Command Setup: Standard library only. Defensive Source Code:

Python import enum

class AllowedCommands(enum.Enum): STATUS \= "system\_status" HEALTH \= "health\_check" METRICS \= "get\_metrics"

def execute\_command(requested\_command: str) \-\> str: valid\_commands \= {cmd.value for cmd in AllowedCommands}

if requested\_command not in valid\_commands: return f"DENY: Operation '{requested\_command}' is not in the allowlist."

return f"Execution of {requested\_command} successful."

Tests and Expected Denials:

Python print(execute\_command("health\_check")) \# Output: Execution of health\_check successful.

print(execute\_command("drop\_tables")) \# Output: DENY: Operation 'drop\_tables' is not in the allowlist. (Expected Denial)

Remaining Limitations: Hardcoded allowlists require software deployments to expand capabilities. Implementing dynamic allowlisting necessitates real-time synchronization with a central policy service.

4. Path Traversal Prevention

Filesystem operations orchestrated by the agent cannot escape a predefined root workspace directory. Command Setup: Standard library only. Defensive Source Code:

Python import os

def safe\_read\_file(base\_dir: str, requested\_file: str) \-\> str: absolute\_base \= os.path.realpath(base\_dir) target\_path \= os.path.realpath(os.path.join(absolute\_base, requested\_file))

if os.path.commonpath(\[absolute\_base, target\_path\]) \!= absolute\_base: return "DENY: Path traversal detected."

if not os.path.isfile(target\_path): return "DENY: File does not exist."

return "ALLOW: File reading permitted."

Tests and Expected Denials:

Python \# Assuming '/app/data' exists print(safe\_read\_file("/app/data", "report.txt")) \# Output: DENY: File does not exist. (Or ALLOW if created)

print(safe\_read\_file("/app/data", "../../etc/passwd")) \# Output: DENY: Path traversal detected. (Expected Denial)

Remaining Limitations: Race conditions can occur if the file system is modified between the realpath resolution and the file read operation (Time-of-Check to Time-of-Use). Operating system file descriptors should be used for absolute guarantee.

5. URL and SSRF Protection

Defend against Server-Side Request Forgery by actively rejecting internal and private IP ranges at the application layer. Command Setup: Standard library only. Defensive Source Code:

Python import ipaddress import urllib.parse import socket

def is\_safe\_url(url: str) \-\> bool: try: parsed \= urllib.parse.urlparse(url) if parsed.scheme not in ('http', 'https'): return False

ip\_addr \= socket.gethostbyname(parsed.hostname) ip\_obj \= ipaddress.ip\_address(ip\_addr)

if ip\_obj.is\_loopback or ip\_obj.is\_private or ip\_obj.is\_reserved: return False return True except Exception: return False

Tests and Expected Denials:

Python print("External URL:", is\_safe\_url("https://www.example.com")) \# Output: External URL: True

print("Localhost URL:", is\_safe\_url("http://127.0.0.1/admin")) \# Output: Localhost URL: False (Expected Denial)

Remaining Limitations: This implementation is highly vulnerable to DNS Rebinding attacks. A truly secure HTTP client must pin the resolved IP address and use it directly for the socket connection rather than re-resolving the hostname.

6. Command Invocation Without Shell Interpolation

Prevent command injection by strictly passing arguments as lists to bypass shell parsing. Command Setup: Standard library only. Defensive Source Code:

Python import subprocess import shlex

def secure\_ping(target\_host: str) \-\> str: if not all(c.isalnum() or c in '.-' for c in target\_host): return "DENY: Invalid characters in target."

command \= \["ping", "-c", "1", target\_host\] try: subprocess.run(command, capture\_output=True, text=True, check=True, shell=False) return "Ping successful." except subprocess.CalledProcessError: return "Ping failed."

Tests and Expected Denials:

Python print(secure\_ping("8.8.8.8")) \# Output: Ping successful.

print(secure\_ping("8.8.8.8; cat /etc/passwd")) \# Output: DENY: Invalid characters in target. (Expected Denial)

Remaining Limitations: Argument arrays do not protect against injection via command-line flags. For instance, passing \--config=/malicious/file instead of a hostname will bypass shell interpolation but still alter program execution.

7. Secret Retrieval Through an Interface

Agents must never possess raw secrets. They must request a mediator to inject them securely at runtime. Command Setup: Standard library only. Defensive Source Code:

Python class SecretMediator: def \_\_init\_\_(self, secrets\_vault: dict): self.\_vault \= secrets\_vault

def make\_authenticated\_request(self, agent\_intent: str, credential\_ref: str) \-\> str: if credential\_ref not in self.\_vault: return "DENY: Invalid credential reference."

real\_secret \= self.\_vault\[credential\_ref\] return f"Request executed securely for {agent\_intent} using reference {credential\_ref}."

vault \= {"aws\_ref\_01": "AKIAIOSFODNN7EXAMPLE"} mediator \= SecretMediator(vault)

Tests and Expected Denials:

Python print(mediator.make\_authenticated\_request("get\_s3\_bucket", "aws\_ref\_01")) \# Output: Request executed securely for get\_s3\_bucket using reference aws\_ref\_01.

print(mediator.make\_authenticated\_request("get\_s3\_bucket", "AKIAIOSFODNN7EXAMPLE")) \# Output: DENY: Invalid credential reference. (Expected Denial)

Remaining Limitations: The host application process must possess advanced memory protections to prevent extraction of the dictionary via side channels or core dumps.

8. Sensitive-Value Redaction

Ensure PII and secrets do not leak into downstream audit logs or model feedback loops. Command Setup: Standard library only. Defensive Source Code:

Python import re

class LogRedactor: def \_\_init\_\_(self): self.patterns \= \[ re.compile(r'AKIA\[0-9A-Z\]{16}'), re.compile(r'\\b(?:\\d{4}\[ \-\]?){3}\\d{4}\\b') \]

def redact(self, log\_message: str) \-\> str: safe\_msg \= log\_message for pattern in self.patterns: safe\_msg \= pattern.sub("\[REDACTED\]", safe\_msg) return safe\_msg

Tests and Expected Denials:

Python redactor \= LogRedactor() unsafe\_log \= "Agent failed using AKIAIOSFODNN7EXAMPLE for account." print(redactor.redact(unsafe\_log)) \# Output: Agent failed using \[REDACTED\] for account.

Remaining Limitations: Regular expressions cannot catch context-dependent sensitive data (e.g., medical diagnoses or corporate strategies). Unstructured PII requires NLP-based Named Entity Recognition (NER) scrubbing.

9. Human Approval Workflow

Force agents to halt execution and await an external cryptographic release token. Command Setup: Standard library only. Defensive Source Code:

Python import threading

class ApprovalGate: def \_\_init\_\_(self): self.\_approved \= threading.Event()

def request\_approval(self, action\_summary: str) \-\> bool: success \= self.\_approved.wait(timeout=1.0) if not success: return False return True

def human\_approve(self): self.\_approved.set()

Tests and Expected Denials:

Python gate \= ApprovalGate() result \= gate.request\_approval("Drop production database") print("Execution result:", result) \# Output: Execution result: False (Expected Denial due to timeout)

Remaining Limitations: Blocking threads is highly inefficient for high-throughput asynchronous APIs. State machines or asynchronous webhooks are mandatory for scalable production deployments.

10. Time-Bounded Authorization

Operations are bound to a strict execution window to prevent stale authorization vectors. Command Setup: Standard library only. Defensive Source Code:

Python import time

def execute\_time\_bound\_task(start\_time: float, max\_duration\_sec: int, task: callable): current\_time \= time.time() if (current\_time \- start\_time) \> max\_duration\_sec: return "DENY: Authorization window expired." return task()

def dummy\_task(): return "Task completed successfully."

Tests and Expected Denials:

Python auth\_time \= time.time() \- 10 print(execute\_time\_bound\_task(auth\_time, 30, dummy\_task)) \# Output: Task completed successfully.

print(execute\_time\_bound\_task(auth\_time, 5, dummy\_task)) \# Output: DENY: Authorization window expired. (Expected Denial)

Remaining Limitations: This logic is highly vulnerable to NTP drift. Host clock synchronization must be mathematically guaranteed across clustered environments to prevent premature expiry or extended access.

11. Scope-Bounded Database Access

Utilize isolated database connections to prevent destructive queries orchestrated by the agent. Command Setup: Standard library only. Defensive Source Code:

Python import sqlite3

def safe\_query(tenant\_id: str, query: str): conn \= sqlite3.connect(':memory:') if not query.strip().upper().startswith("SELECT"): return "DENY: Only SELECT queries are permitted by this capability."

cursor \= conn.cursor() safe\_sql \= f"SELECT \* FROM ( {query} ) WHERE tenant \= ?" try: cursor.execute(safe\_sql, (tenant\_id,)) return cursor.fetchall() except Exception as e: return f"Database error gracefully handled: {e}"

Tests and Expected Denials:

Python print(safe\_query("tenant\_1", "SELECT id, data FROM user\_data")) \# Output: Database error gracefully handled: no such table: user\_data

print(safe\_query("tenant\_1", "DROP TABLE users")) \# Output: DENY: Only SELECT queries are permitted by this capability. (Expected Denial)

Remaining Limitations: Complex Common Table Expressions (CTEs) or stacked queries may evade naive string checks. True mitigation requires Database RBAC or Row-Level Security (RLS) policies implemented at the engine level20.

12. Signed Audit Event

Ensure logs cannot be tampered with by generating an append-only cryptographic signature chain. Command Setup: Standard library only. Defensive Source Code:

Python import hashlib import json

class AuditLedger: def \_\_init\_\_(self): self.last\_hash \= hashlib.sha256(b"genesis\_block").hexdigest()

def record\_event(self, agent: str, action: str) \-\> dict: event \= { "agent": agent, "action": action, "prev\_hash": self.last\_hash } event\_bytes \= json.dumps(event, sort\_keys=True).encode() current\_hash \= hashlib.sha256(event\_bytes).hexdigest() self.last\_hash \= current\_hash

return {"event": event, "signature": current\_hash}

Tests and Expected Denials:

Python ledger \= AuditLedger() print(ledger.record\_event("Agent1", "Read File")\['signature'\]) print(ledger.record\_event("Agent1", "Write File")\['signature'\]) \# Output: Two distinct SHA256 hashes forming a chain.

Remaining Limitations: An attacker gaining root access can delete the entire ledger or recalculate the hashes from the point of intrusion. Ledger logs must be instantly streamed to an external write-once-read-many (WORM) datastore.

13. Policy Evaluation

Local simulation of an external PDP (such as Cedar or Cerbos) evaluating context attributes. Command Setup: Standard library only. Defensive Source Code:

Python def evaluate\_policy(principal: dict, action: str, resource: dict) \-\> bool: decision \= False

if action \== "read": if "read\_group" in principal.get("roles", \[\]): if principal.get("department") \== resource.get("department"): decision \= True

return decision

Tests and Expected Denials:

Python agent \= {"id": "ag\_1", "roles": \["read\_group"\], "department": "finance"} res\_valid \= {"id": "doc\_1", "department": "finance"} res\_invalid \= {"id": "doc\_2", "department": "hr"}

print("Same department:", evaluate\_policy(agent, "read", res\_valid)) \# Output: Same department: True

print("Cross department:", evaluate\_policy(agent, "read", res\_invalid)) \# Output: Cross department: False (Expected Denial)

Remaining Limitations: Hardcoded Python policies degrade rapidly into unmaintainable state machines. Utilizing formalized engines provides mathematical verifiability and centralized lifecycle management3.

14. Sandboxed Subprocess Boundary

Isolate LLM-generated Python code by stripping it of standard library system capabilities. Command Setup: Standard library only. Defensive Source Code:

Python import builtins

def execute\_sandboxed\_code(user\_code: str): safe\_globals \= { "\_\_builtins\_\_": { "print": builtins.print, "range": builtins.range, "len": builtins.len } }

try: exec(user\_code, safe\_globals, {}) return "Execution succeeded." except Exception as e: return f"DENY/ERROR: {e}"

Tests and Expected Denials:

Python malicious\_code \= "import os\\nos.system('echo hacked')" safe\_code \= "print(len(range(10)))"

print(execute\_sandboxed\_code(safe\_code)) \# Output: Execution succeeded.

print(execute\_sandboxed\_code(malicious\_code)) \# Output: DENY/ERROR: \_\_import\_\_ not found (Expected Denial)

Remaining Limitations: Python's exec module is notoriously difficult to sandbox perfectly due to introspection capabilities (e.g., \_\_class\_\_.\_\_subclasses\_\_). Wasmtime24 is strictly recommended for production sandboxing over Python namespace manipulation.

15. Safe Deserialization

Prevent pickle exploits by forcing strict schema validation via typed data classes. Command Setup: pip install pydantic (Standard dataclass used here for baseline). Defensive Source Code:

Python from dataclasses import dataclass, field import json

@dataclass class SafePayload: user\_id: int action: str metadata: dict \= field(default\_factory=dict)

def process\_payload(json\_data: str) \-\> str: try: data\_dict \= json.loads(json\_data) if not isinstance(data\_dict.get("user\_id"), int): return "DENY: Type mismatch on user\_id."

obj \= SafePayload(\\data\_dict) return f"Processed safely: {obj.action}" except (json.JSONDecodeError, TypeError) as e: return f"DENY: Malformed payload \- {e}"

Tests and Expected Denials:

Python print(process\_payload('{"user\_id": 123, "action": "update"}')) \# Output: Processed safely: update

print(process\_payload('{"user\_id": "admin", "action": "update"}')) \# Output: DENY: Type mismatch on user\_id. (Expected Denial)

Remaining Limitations: Deeply nested JSON structures can still trigger CPU exhaustion (Billion Laughs style attacks). Depth and payload size limitations must be strictly enforced prior to initiating the parsing routine.

16. Rate and Resource Limits

Block denial of service attacks by bounding invocation frequency in compliance with OWASP LLM1025. Command Setup: Standard library only. Defensive Source Code:

Python import time

class RateLimiter: def \_\_init\_\_(self, max\_requests: int, window\_sec: int): self.max\_requests \= max\_requests self.window\_sec \= window\_sec self.requests \= \[\]

def check\_limit(self) \-\> bool: now \= time.time() self.requests \= \[req for req in self.requests if req \> now \- self.window\_sec\]

if len(self.requests) \>= self.max\_requests: return False

self.requests.append(now) return True

Tests and Expected Denials:

Python limiter \= RateLimiter(max\_requests=2, window\_sec=10) print(limiter.check\_limit()) \# True print(limiter.check\_limit()) \# True print(limiter.check\_limit()) \# False (Expected Denial)

Remaining Limitations: In-memory limits fail to synchronize in distributed architectures. A centralized data store such as Redis, utilizing atomic Lua execution scripts, is necessary for multi-node deployments.

17. Rejection Proving No Partial Side Effect

Ensure atomic transactions so that partial errors do not leave downstream systems in corrupted states. Command Setup: Standard library only. Defensive Source Code:

Python class ContextTransaction: def \_\_init\_\_(self): self.state \= {} self.backup \= {}

def \_\_enter\_\_(self): self.backup \= self.state.copy() return self.state

def \_\_exit\_\_(self, exc\_type, exc\_val, exc\_tb): if exc\_type is not None: self.state.clear() self.state.update(self.backup) print("DENY: Transaction rolled back due to error.") return True

Tests and Expected Denials:

Python db \= ContextTransaction() db.state \= {"val": 1}

with db as txn: txn\["val"\] \= 2 raise ValueError("Agent logical error midway.")

print("State after failure:", db.state) \# Output: DENY: Transaction rolled back... \# State after failure: {'val': 1} (Expected Rejection/Rollback)

Remaining Limitations: Memory rollbacks do not automatically apply to external systems (e.g., HTTP requests fired, emails sent). Saga patterns are required for distributed transactions to execute compensating actions11.

18. Security-Focused Tests and Fuzz Cases

Automated boundary testing designed to feed adversarial payloads into input validation boundaries. Command Setup: Standard library only. Defensive Source Code:

Python def input\_boundary(user\_input: str) \-\> bool: if len(user\_input) \> 20: return False if "\<" in user\_input or "\>" in user\_input: return False return True

def fuzz\_test\_boundary(): test\_cases \= \[ "normal\_string", "A" \* 50, "\<script\>alert(1)\</script\>", "../../etc/passwd" \]

return \[input\_boundary(tc) for tc in test\_cases\]

Tests and Expected Denials:

Python print("Fuzz results:", fuzz\_test\_boundary()) \# Output: Fuzz results: \[True, False, False, True\] \# (Expected Denials on lengths and brackets; traversal is handled in module 4\)

Remaining Limitations: Basic array testing is deterministic and limited in scope. True fuzzing requires property-based testing libraries like Hypothesis to explore vast combinatorial state spaces mathematically.

E. Related-Project Directory

This directory profiles 25 critical projects within the Python and AI ecosystem addressing architecture, isolation, policy management, and security26.

Policy Engines

Sandboxing Systems

Secure HTTP Clients

Static Analyzers & Dependency Auditors

Capability-Oriented Frameworks

Cryptographic & Identity Libraries

Secret Managers

Additional Defensive & Utility Projects

F. Policy and Isolation Decision Matrices

Selecting the appropriate boundary control relies heavily on analyzing operational capability against organizational threat tolerance. The following matrices evaluate standard engineering trade-offs required when governing AI systems.

G. Security Checklist for Agentic Systems

The verification of boundary implementations requires a standardized checklist utilized during CI/CD audits.

H. Architectural Source Ledger: The Intent-to-Execution Evidence Chain (IEEC)

To guarantee operational accountability across the platform, OntologicalMachine.com implements an Intent-to-Execution Evidence Chain (IEEC)3. In traditional architectures, APIs perform CRUD (Create, Read, Update, Delete) operations directly upon receiving a valid request. When managing autonomous agents, direct mutation introduces unacceptable risk. Instead of mutating state directly, agents submit cryptographically signed intent proposals to the gateway. This sequence generates an unalterable cryptographic ledger that records the following distinct components:

1. Context Snapshot: The exact state of the system, including the agent's trust score, temporal signals, and relevant environmental data when the prompt was evaluated.

2. Policy Decision: The explicit, deterministic Allow or Deny boolean generated by the Policy Decision Point (PDP) evaluating the intent against the context3.

3. Execution Contract: The exact boundary parameters, resource IDs, and network boundaries the agent is permitted to touch during this specific transaction.

4. Outcome Hash: A checksum of the resulting mutation applied to the system, linked sequentially to the prior log entry's hash.

This methodology transforms opaque infrastructure mutation into a deterministic, auditable, and mathematically replayable process. By storing the exact context and policy decision alongside the action, security teams can explicitly prove that no hidden autonomous state divergence occurred, satisfying complex compliance mandates3.

I. Integration JSON Configuration

The following configuration defines the JSON schema for boundary integration. It explicitly enforces capability mapping, isolation standards, and authorization schemas dynamically at application boot time, ensuring security configurations are treated as immutable infrastructure.

JSON { "ontological\_machine\_security": { "agent\_mesh": { "execution\_ring": 2, "isolation\_model": "wasm\_sandbox", "pdp\_engine": "cerbos", "policy\_version": "v1.2.0" }, "tool\_registry": { "default\_policy": "deny", "allowlist": \[ { "action": "filesystem:read", "resource\_boundary": "/var/run/agent/workspace", "max\_duration\_ms": 500 }, { "action": "network:http\_get", "url\_allowlist\_regex": "^https://api\\\\.safe-vendor\\\\.com/.\*", "block\_private\_ips": true } \] }, "human\_in\_the\_loop": { "required\_for": \[ "database:write", "infrastructure:deploy", "iam:modify\_roles" \], "timeout\_sec": 300 }, "telemetry": { "redact\_pii": true, "audit\_format": "ieec\_signed\_ledger", "export\_endpoint": "https://telemetry.internal/audit" } } }

Works cited

1. Zero Trust Architecture, https://tsapps.nist.gov/publication/get\_pdf.cfm?pub\_id=930420

2. Zero Trust Architecture \- NIST, https://www.nist.gov/publications/zero-trust-architecture

3. OpenKedge: Governing Agentic Mutation with Execution-Bound, https://arxiv.org/html/2604.08601v1

4. Secure Your Architecture With Externalized Authorization \- Cerbos, https://www.cerbos.dev/for-architects

5. From OPA to Our Own Engine \- the Cerbos Journey, https://www.cerbos.dev/blog/from-opa-to-our-own-engine-cerbos

6. OWASP Top 10 for LLM Applications Explained (2026) \- Checkmarx, https://checkmarx.com/learn/breaking-down-the-owasp-top-10-for-llm-applications/

7. Demystifying the OWASP Top 10 for Agentic Applications \- Medium, https://idanhabler.medium.com/demystifying-the-owasp-top-10-for-agentic-applications-4eedba941b2c

8. OWASP Top 10 for Large Language Model Applications, https://owasp.org/www-project-top-10-for-large-language-model-applications/

9. OWASP LLM top 10: A practitioner's guide to LLM security risks \- Wiz, https://www.wiz.io/academy/ai-security/owasp-llm-top-10

10. Generate Autonomous Business Insights with AI Agent and MCP, https://aws.amazon.com/blogs/machine-learning/generate-autonomous-business-insights-with-ai-agent-and-mcp-servers/

11. agent-governance-toolkit/docs/modern-agent-architecture-overview, https://github.com/microsoft/agent-governance-toolkit/blob/main/docs/modern-agent-architecture-overview.md

12. OWASP Top 10 for LLM Applications \- Complete Guide \- Securiti.ai, https://securiti.ai/owasp-top-10-for-llms/

13. Simon Willison on files-to-prompt, https://simonwillison.net/tags/files-to-prompt/

14. Landlock: unprivileged access control — The Linux Kernel, https://docs.kernel.org/6.1/userspace-api/landlock.html

15. OWASP Singapore Chapter, https://owasp.org/www-chapter-singapore/

16. noahwilliamshaffer/DAST-SAST-Security-Testing-Pipeline \- GitHub, https://github.com/noahwilliamshaffer/DAST-SAST-Security-Testing-Pipeline

17. OWASP top 10 for LLM F5 alignment, https://www.f5.com/resources/infographic/owasp-llm-top10

18. developmentseed/action-python-security-auditing: A ... \- GitHub, https://github.com/developmentseed/action-python-security-auditing

19. Agentic Data Onboarding Platform(ADOP) — an AI-driven ... \- GitHub, https://github.com/aws-samples/sample-Agentic-Ai-Data-Operations

20. Cerbos Policy Decision Point: Open-Source Authorization Solution, https://www.cerbos.dev/product-cerbos-pdp

21. OWASP Top 10 for LLMs Explained | CrowdStrike, https://www.crowdstrike.com/en-us/cybersecurity-101/artificial-intelligence/owasp-top-10-for-large-language-model-applications/

22. Terms & concepts | Cedar Policy Language Reference Guide, https://docs.cedarpolicy.com/overview/terminology.html

23. GitHub \- nscuro/dtapac: Audit Dependency-Track findings and policy, https://github.com/nscuro/dtapac

24. wasmtime-py/pyproject.toml at main · bytecodealliance/wasmtime-py, https://github.com/bytecodealliance/wasmtime-py/blob/main/pyproject.toml

25. OWASP LLM Top 10 2026 and the Agentic Top 10: Full Coverage, https://www.daxa.ai/blogs/owasp-llm-agentic-top-10

26. starred/by-language.md at master · b0o/starred \- GitHub, https://github.com/b0o/starred/blob/master/by-language.md

27. dev-trackers/awesome-python-1 \- GitHub, https://github.com/dev-trackers/awesome-python-1

28. awesome-python/README.md at main \- GitHub, https://github.com/dylanhogg/awesome-python/blob/main/README.md

29. Serverless Policy Enforcement: Connecting OPA and AWS Lambda, https://www.openpolicyagent.org/blog/serverless-policy-enforcement-connecting-opa-and-aws-lambda-e624f7176a3

30. joseflys vs httpx \- compare differences and reviews? \- LibHunt, https://www.libhunt.com/compare-joseflys-vs-httpx

31. Fatal1ty/awesome-stars: A curated list of my ... \- GitHub, https://github.com/Fatal1ty/awesome-stars

32. GitHub \- amakhu/cdp, https://github.com/amakhu/cdp

33. pawamoy/stars: My stars on GitHub, grouped by language., https://github.com/pawamoy/stars

34. pylint(1) \- Arch manual pages, https://man.archlinux.org/man/pylint

35. agent-governance-toolkit/docs/FAQ.md at main · microsoft ... \- GitHub, https://github.com/microsoft/agent-governance-toolkit/blob/main/docs/FAQ.md

36. Framework for Evaluating Authorization Providers and Solutions, https://www.cerbos.dev/blog/framework-evaluating-authorization-providers-solutions

37. Governing AI Coding Agents With Cerbos Synapse, https://www.cerbos.dev/blog/governing-ai-coding-agents-with-cerbos-synapse