DEV Community: jaryn

Audit an AI Coding CLI Before It Uploads Your Home Directory

jaryn — Mon, 13 Jul 2026 14:15:59 +0000

Reports that a coding CLI transmitted unexpectedly broad local data are trending today. A social post is a lead, not a verdict, so the useful response is a reproducible audit.

Start with a disposable VM, a canary home directory, and a proxy you control. Put unique strings in ~/Documents/canary.txt, .env.test, Git configuration, and a fake SSH filename. Never use real secrets.

mkdir -p "$HOME/audit-home/Documents"
printf 'CANARY_DOC_7f31\n' > "$HOME/audit-home/Documents/canary.txt"
printf 'FAKE_TOKEN=CANARY_ENV_b921\n' > "$HOME/audit-home/.env.test"

Run the CLI with that directory as HOME, deny access to the real home directory, and capture DNS, destination host, method, content type, byte count, and request timing. If TLS inspection is permitted in your environment, search decoded request bodies for the canaries. Otherwise compare encrypted byte volume while adding one fixture at a time.

Use four tests: empty prompt, prompt referencing one file, explicit repository upload, and a prompt-injection file asking the agent to read another directory. Record the exact CLI version, configuration, consent screen, and network policy.

The acceptance rule should be simple: every transmitted file must be attributable to an explicit user action or a documented minimal context rule. Block unknown destinations, require a preview for bulk transfer, and keep an append-only transfer manifest with paths hashed or redacted.

MonkeyCode is an open-source coding platform where this same boundary matters for workspaces and model backends. I contribute to the project; this is a tool-independent test plan, not a claim about MonkeyCode or the reported CLI incident.

Do not argue from packet size alone. Publish the fixture, version, capture method, observed destinations, and limitations so others can reproduce the result without exposing personal data.

Threat-Model an MCP Server as a Privileged API Gateway

jaryn — Mon, 13 Jul 2026 02:41:28 +0000

An MCP server is often introduced as a convenient adapter between an assistant and an API. Security-wise, it is a privileged gateway accepting model-influenced requests.

The important question is not whether a tool is called read_dashboard or fix_incident. It is which identities, resources, side effects, and networks the implementation can reach.

Inventory authority per tool

Tool	Read scope	Write scope	Credential	Approval
`get_metric`	one tenant, named metric	none	read-only service token	none
`create_ticket`	incident summary	ticket system	create-only token	preview
`restart_service`	service status	one deployment	short-lived workload token	exact-call approval

Do not give every tool the server process's full credential. Split read and write identities, scope them to a tenant and resource class, and mint short-lived tokens near execution.

Treat arguments as untrusted

const Restart = z.object({
  service: z.enum(["api", "worker"]),
  environment: z.literal("staging"),
  reason: z.string().min(20).max(500),
  operationId: z.string().uuid(),
}).strict();

Strict schemas reject unexpected fields. Server-side authorization must still verify the caller, tenant, current resource state, and policy version. Never turn a model-provided URL, path, shell fragment, SQL clause, or header into raw authority.

For consequential calls, show a preview generated from validated arguments. Bind approval to the user, tool name, canonical arguments, policy version, resource version, and expiry. If any changes, ask again.

Log evidence, not secrets

Record request ID, actor, tool, canonical argument hash, target resource, policy decision, credential identity, result class, and timing. Redact tokens, cookies, prompts containing credentials, and raw third-party responses. Make duplicate operationId calls return the original result instead of repeating a side effect.

Test prompt injection in tool output, cross-tenant IDs, unknown arguments, stale approval, duplicate delivery, timeout after a successful remote write, credential revocation, and log redaction.

The public MonkeyCode repository describes model management, AI tasks, development environments, and private deployment. MCP-style integrations may be relevant to such platforms, but this article neither claims a current MonkeyCode MCP implementation nor reports a security test of one.

Disclosure: I contribute to the MonkeyCode project. Product context comes from public documentation; the threat model is tool-independent.

Naming a capability as a tool does not reduce its authority. Design the gateway as though untrusted input can reach every exposed schema—because eventually it will.

Stop Mass Assignment Before It Reaches Your Authorization Layer

jaryn — Sun, 12 Jul 2026 15:12:09 +0000

Mass assignment is what happens when an API treats the request body as the update policy.

await db.users.update(req.params.id, { ...req.body });

That line is convenient until a client sends role, accountId, credit, or emailVerified. Validation alone does not answer whether this caller may change a valid field. The safer design has three separate gates: accepted fields, valid values, and authorized transitions.

Build a mutation contract

const MUTATIONS = {
  displayName: {
    validate: (v) => typeof v === "string" && v.trim().length <= 80,
    authorize: ({ actor, target }) =>
      actor.id === target.id || actor.permissions.includes("users:write"),
    normalize: (v) => v.trim(),
  },
  timezone: {
    validate: (v) => Intl.supportedValuesOf("timeZone").includes(v),
    authorize: ({ actor, target }) => actor.id === target.id,
    normalize: (v) => v,
  },
};

export function buildPatch(body, context) {
  const patch = {};
  const rejected = [];

  for (const [field, value] of Object.entries(body)) {
    const rule = MUTATIONS[field];
    if (!rule || !rule.validate(value) || !rule.authorize(context)) {
      rejected.push(field);
      continue;
    }
    patch[field] = rule.normalize(value);
  }
  return { patch, rejected };
}

An allowlist makes new database columns non-writable by default. Per-field authorization prevents a broad “can edit user” check from granting authority over every property. Returning rejected field names to server-side telemetry makes probing visible; do not echo sensitive values.

Test forbidden fields as invariants

import assert from "node:assert/strict";

const actor = { id: "u1", permissions: [] };
const target = { id: "u1", role: "member", accountId: "a1" };
const { patch, rejected } = buildPatch(
  { displayName: " Ada ", role: "admin", accountId: "a2" },
  { actor, target },
);

assert.deepEqual(patch, { displayName: "Ada" });
assert.deepEqual(rejected.sort(), ["accountId", "role"]);

Also test duplicate JSON keys at the HTTP parser boundary, nested objects, null, arrays, Unicode normalization, and races where authorization changes between read and write. Apply the database update with a condition on the version or authorization-relevant state; otherwise a correct pre-check can become stale.

Log the actor, target, accepted field names, rejected field names, policy version, and result. Never log bearer tokens or entire request bodies.

The public MonkeyCode repository describes project requirements, task management, team collaboration, and private deployment. Any platform that accepts structured updates for tasks, projects, or permissions benefits from explicit mutation contracts. This example is independent and does not claim a MonkeyCode vulnerability or describe its internal API.

Disclosure: I contribute to the MonkeyCode project. The product context comes from its public repository; no security test of MonkeyCode is reported here.

The important boundary is simple: a request body proposes data. It never defines its own authority.

Use SQLite STRICT Tables for Agent Control Data

jaryn — Sun, 12 Jul 2026 08:07:08 +0000

An AI coding workflow may generate probabilistic output, but its authority should not be probabilistic. Task state, approval scope, repository identity, and policy version are control data. If one of those values is malformed, silently coercing it is a dangerous default.

This is why the current discussion around SQLite strict tables is relevant to agent systems. At 2026-07-12 08:00 UTC, Evan Hahn's article “Prefer strict tables in SQLite” was the highest-scoring item in the Hacker News snapshot I reviewed, with 267 points. SQLite's own STRICT tables documentation is the source of truth for the feature.

The useful lesson is narrower than “make everything strict”: put strong boundaries around the small set of records that decide what an automated tool may do.

A control-data schema

CREATE TABLE agent_task (
  task_id TEXT PRIMARY KEY,
  repo_id TEXT NOT NULL,
  requested_by TEXT NOT NULL,
  state TEXT NOT NULL CHECK (
    state IN ('queued', 'running', 'awaiting_approval', 'succeeded', 'failed', 'cancelled')
  ),
  policy_version TEXT NOT NULL,
  approved_commit TEXT,
  approval_expires_at INTEGER,
  created_at INTEGER NOT NULL,
  updated_at INTEGER NOT NULL
) STRICT;

CREATE TABLE tool_grant (
  task_id TEXT NOT NULL REFERENCES agent_task(task_id),
  tool TEXT NOT NULL,
  resource_pattern TEXT NOT NULL,
  effect TEXT NOT NULL CHECK (effect IN ('allow', 'deny')),
  granted_by TEXT NOT NULL,
  expires_at INTEGER NOT NULL,
  PRIMARY KEY (task_id, tool, resource_pattern)
) STRICT;

STRICT does not create a complete authorization system. It does make invalid storage less ambiguous: values must be compatible with the declared types, and SQLite reports a constraint error rather than accepting arbitrary type substitutions. CHECK constraints still carry the domain rules.

Validate the decision, not only the row

Before a worker changes a repository, the application should evaluate all of these inputs together:

Question	Reject when
Is this the intended repository?	`repo_id` does not match the checked-out remote
Is the approval current?	expiry is in the past or absent for a privileged tool
Is the code revision pinned?	`approved_commit` differs from the worker's base commit
Is the policy reproducible?	`policy_version` cannot be loaded
Is the transition legal?	current and requested states are not an allowed edge

A defensive transition can be one conditional statement:

UPDATE agent_task
SET state = 'running', updated_at = unixepoch()
WHERE task_id = :task_id
  AND state = 'queued'
  AND policy_version = :loaded_policy;

The worker proceeds only when exactly one row changed. That turns a race or stale assumption into a visible failure.

Threat model and limits

This boundary helps with accidental type coercion, illegal states, stale approvals, and concurrent transitions. It does not stop a process that can rewrite the database file, bypass the application, steal signing credentials, or alter the policy loader. File permissions, process isolation, append-only audit export, backups, and independent review remain separate controls.

Run PRAGMA integrity_check; as part of recovery testing, but do not confuse integrity with authorization. A structurally valid database can still contain a maliciously granted permission.

Where MonkeyCode fits

The public MonkeyCode repository describes an open-source AI coding platform with AI task, development-environment, model, and project-requirement management, plus private deployment. That makes control-data boundaries relevant when evaluating a deployment. The schema above is an independent review pattern; it is not a claim about MonkeyCode's internal database design.

Disclosure: I contribute to the MonkeyCode project. The observations and limitations below are based on the linked repository and the test setup described in this article.

If you are evaluating the platform, ask the team in the MonkeyCode Discord how task state, approvals, and policy versions are represented in the version you plan to run. You can also ask whether free model credits are currently available and confirm eligibility and usage limits.

The practical rule is simple: model output can remain flexible; the records that grant authority should fail closed.

Threat-Modeling MonkeyCode as a Self-Hosted AI Coding Platform

jaryn — Fri, 10 Jul 2026 10:06:35 +0000

Self-hosting changes who operates an AI coding platform. It does not make the platform trusted by default.

An AI development task can combine repository content, model output, shell commands, credentials, package registries, preview servers, and human approval. That is a much larger authority surface than a chat box. The useful security question is not “is it open source?” It is “which input can cause which side effect across which trust boundary?”

This article uses MonkeyCode as a worked example because its public README describes private deployment, managed development environments, model management, AI task management, and project requirements. I reviewed the repository documentation at commit 1ac778f. This is a design review, not a penetration test or a claim about a deployed instance.

Start with authority, not components

A component diagram often says where services run. A threat model must also say what they can do.

developer browser
      |
      | identity, task text, approvals
      v
control plane ---------> model endpoint
      |                       ^
      | task + policy         | prompt / response
      v                       |
workspace runner ------------+
      |
      +--> repository credentials
      +--> package registries
      +--> build tools and shell
      +--> preview endpoint

The exact MonkeyCode implementation may divide these responsibilities differently. The diagram is an explicit review model inferred from the capabilities in the README. Replace it with the real topology before using the checklist for an approval decision.

For every arrow, record four fields:

Field	Question
Principal	Which human or service initiated the action?
Input	Is the data trusted, untrusted, or generated?
Authority	Can the receiver read files, run commands, reach a network, or change a repository?
Evidence	Which log proves the decision and result?

This catches a common modeling mistake: treating model output as data while quietly giving the consumer permission to execute it.

Five abuse cases to model first

1. Repository content becomes instructions

A README, issue, test fixture, or dependency can contain text that attempts to redirect an agent. The control is not a better system prompt. Keep authorization in deterministic policy: permitted tools, path scopes, command classes, network destinations, and approval gates.

Test property:

Untrusted repository text cannot expand the task's original authority.

2. A workspace exposes a credential

Credentials may enter through Git remotes, environment variables, package-manager configuration, cloud metadata, or copied logs. Prefer short-lived task credentials and mount only the secret needed for the current operation. Redaction is a backup control, not the primary boundary.

Test property:

A task that prints its environment cannot recover another task's secrets.

3. One task reaches another workspace

For a team platform, process separation is not automatically tenant separation. Review filesystem namespaces, container privileges, shared caches, Docker sockets, host mounts, preview routing, and cleanup after cancellation.

Test property:

Knowing another task ID or path does not grant read, write, signal, or preview access.

4. Dependency installation becomes unrestricted egress

Builds legitimately contact registries, but unrestricted outbound access also creates an exfiltration path. Define whether a workspace can reach the public internet, internal services, cloud metadata, and arbitrary model endpoints. Log denied destinations without logging secret-bearing URLs.

5. Generated code crosses into a trusted branch

The last boundary is often Git, not the model. Protect the default branch with human review, required tests, scoped repository tokens, signed provenance where appropriate, and a patch-size or sensitive-path gate.

A control matrix that can fail closed

Use a matrix like this during deployment review:

Boundary	Prevent	Detect	Recover
Browser → control plane	SSO, MFA, role checks, CSRF protection	auth and admin audit log	revoke sessions and tokens
Control plane → runner	signed task identity, policy snapshot, least privilege	immutable task/tool events	cancel and quarantine workspace
Runner → repository	short-lived scoped token, protected branches	commit and push audit	revoke token, revert patch
Runner → network	destination policy, metadata block	DNS/connection telemetry	isolate runner, rotate exposed secrets
Task → task	per-task identity and filesystem isolation	cross-scope denial events	destroy affected workers and caches
Runner → preview	authenticated routing, safe headers, expiry	access logs tied to task ID	revoke route and terminate process

“Prevent, detect, recover” matters. A control list containing only prevention assumes the first layer never fails.

Make the review reproducible

Pin the source revision and keep the evidence beside the decision:

git clone https://github.com/chaitin/MonkeyCode.git
cd MonkeyCode
git checkout 1ac778fdba1da1b353f7f5672d2e4550801cf46d

rg -n "privileged|docker.sock|hostNetwork|hostPath" .
rg -n "Authorization|token|secret|password" backend frontend
rg -n "exec|spawn|shell|command" backend

These searches do not prove a vulnerability or prove safety. They create a repeatable starting set for manual tracing. For each relevant hit, document the call path, input origin, permission check, secret handling, emitted audit event, and failure behavior.

Then run adversarial tests in a disposable environment:

submit repository text that requests an unrelated command;
attempt to read a sibling workspace and a host path;
request cloud metadata and an unapproved network destination;
print likely secret locations and inspect every log surface;
cancel during clone, dependency install, build, and repository write;
reuse expired task and repository credentials;
request a preview URL from another authenticated user.

Record a version, topology, test identity, expected denial, actual result, and evidence location for every case. “Blocked” without a log or packet trace is not a result another reviewer can reproduce.

What the public repository does and does not establish

The official documentation supports that MonkeyCode is AGPL-3.0 open source and offers private deployment. That makes source review and operator control possible. It does not, by itself, establish isolation strength, a compliance outcome, or secure configuration for a particular deployment. Those conclusions require the actual topology, version, identity provider, secret flow, runner privileges, network policy, and adversarial test results.

Disclosure: I contribute to the MonkeyCode project. This threat model is based on the linked public repository and documentation, not an independent security audit.

If you are evaluating a self-hosted setup, join the MonkeyCode Discord to discuss the deployment model with the team. You can also ask there about currently available free model credits; confirm eligibility and usage limits before planning around them.

The safest output of a threat model is not a “secure” label. It is a short list of authority claims that can be denied, observed, and retested after every meaningful deployment change.

Threat-Modeling an LLM Feature Before It Reaches Production

jaryn — Fri, 10 Jul 2026 07:11:43 +0000

Adding an LLM to an application creates a new interpreter for untrusted text. That interpreter may also retrieve private data, call tools, or write to other systems. The useful security question is therefore not “Is the model safe?” but “What can data flowing through the model cause the application to do?”

Here is a compact threat-modeling method for answering that question before launch.

Start with assets, not prompts

List what the feature must protect. For a support assistant, the list might include:

customer messages and attachments;
retrieved account records;
system instructions and internal policies;
tool credentials;
actions such as refunds, password resets, and ticket updates;
logs, traces, and evaluation datasets.

This prevents a common modeling mistake: treating prompt injection as the whole problem. Injection is one path. The asset and the reachable action determine its impact.

Draw the trust boundaries

A minimal LLM feature often has more boundaries than its UI suggests:

user input
   |
   v
application API ---> model provider
   |                     |
   v                     v
retrieval index       generated text
   |
   v
tool executor ---> business systems

Mark every place where data changes authority or ownership. User text is untrusted. Retrieved documents may also be untrusted if users can upload or edit them. Model output is untrusted even when the application supplied a careful system prompt. A tool response can contain hostile instructions too.

That last point matters in retrieval-augmented systems: a document is data to the application, but the model may interpret it as an instruction.

Write abuse cases as data flows

Use concrete “input → interpretation → effect” statements. For example:

Input path	Unsafe interpretation	Possible effect
Uploaded PDF	Text overrides the system instruction	Private retrieval results appear in output
Tool argument	Generated account ID is accepted as authoritative	One user acts on another user’s record
Model response	Markdown link is rendered without checks	Phishing or unsafe navigation
Trace pipeline	Full prompts are retained by default	Secrets persist in logs

This format is easier to turn into controls and tests than a label such as “prompt injection risk.”

Put authorization outside the model

The model may propose an action; application code must decide whether it is allowed.

For every tool, define:

a narrow input schema;
server-side identity and permission checks;
limits on scope, amount, and frequency;
a confirmation step for consequential actions;
an audit record that does not expose unnecessary prompt data.

Do not let the model select a user identity, tenant, or authorization scope from free text. Derive those values from the authenticated session. A refund tool, for example, should receive an order ID but obtain the customer and maximum refundable amount from trusted backend state.

“The system prompt says not to” is not an authorization control.

Separate content from instructions

When retrieved or uploaded text enters a prompt, delimit and label it as data. This can reduce accidental instruction mixing, but it is not a complete defense. Enforce the important boundary after generation:

validate structured output against a schema;
allowlist tool names and argument shapes;
sanitize or safely render links and markup;
filter retrieval by the caller’s permissions before context reaches the model;
require deterministic policy checks before side effects.

The goal is to make a successful injection produce an untrusted suggestion, not an authorized action.

Test properties, not magic phrases

A useful adversarial suite varies the attack path:

direct instructions in the user message;
indirect instructions inside retrieved documents;
encoded, multilingual, fragmented, or quoted instructions;
attempts to cross tenants or retrieve hidden fields;
malformed tool arguments and repeated tool calls;
attempts to place secrets in output or telemetry.

Assertions should describe system properties: “No document outside the caller’s tenant appears,” “A tool call without server-side authorization is rejected,” or “A generated URL cannot use an unsafe scheme.” Exact output matching is usually too brittle for this layer.

Run these cases whenever prompts, models, retrieval rules, or tools change. A model update is a behavior change even when the API contract stays the same.

Plan containment and evidence

Assume one control will fail. Useful containment options include read-only tools by default, per-tool rate limits, small transaction limits, short-lived credentials, human confirmation, and an immediate tool kill switch.

Collect enough evidence to investigate failures: request and tool-call IDs, model and prompt versions, policy decisions, timing, and redacted error categories. Avoid treating complete prompts as harmless debug strings; they can contain personal data, credentials, and proprietary context.

A pre-launch review

Before enabling the feature, the team should be able to answer:

Which inputs are attacker-controlled, including retrieved content?
Which private assets can enter model context?
Which side effects are reachable, and who authorizes each one?
What validation happens after generation?
What is logged, retained, and redacted?
Which adversarial cases run in CI or release evaluation?
How can operators disable tools without disabling the whole product?

Two useful baselines are the OWASP Top 10 for LLM Applications and NIST’s AI 600-1 Generative AI Profile. They are most valuable as inputs to a system-specific review, not as checklists that certify a design.

An LLM can remain probabilistic while the surrounding security boundary stays explicit. Keep authority in deterministic code, minimize what the model can reach, and test the paths where untrusted text meets privileged actions.

GPT-5.6 Passed Government Safety Review — But What Does That Actually Mean?

jaryn — Fri, 10 Jul 2026 04:17:02 +0000

The news dropped like it was supposed to be reassuring: GPT-5.6 — OpenAI's latest model suite including Sol, Terra, and Luna — has been reviewed and approved by the U.S. government.

But here's what bothers me about this.

What "government approved" actually means

When we hear "government safety review," we imagine rigorous testing. Scientists in lab coats running adversarial prompts. Red teams trying to break the model. Extensive documentation of failure modes.

The reality is closer to: OpenAI submitted internal testing results, the government looked at them, and said "okay."

That's not safety testing. That's a rubber stamp with extra steps.

The Sol-Terra-Luna lineup

The three models are designed for different use cases:

Sol: The flagship. Largest context window, most capable reasoning. Think GPT-4 but with actual common sense improvements.
Terra: Mid-tier. Good enough for most enterprise tasks at a fraction of Sol's cost.
Luna: The lightweight. Fast, cheap, designed for high-volume API calls.

On paper, this is smart product segmentation. In practice, it means OpenAI now has a model at every price point, which is great for their revenue and potentially problematic for competition.

Why I'm skeptical

A few things don't add up:

Speed of approval: GPT-5 development started relatively recently. How thorough could the review have been?
No public methodology: We don't know what tests were run, what thresholds were applied, or what edge cases were considered.
Self-reported data: OpenAI essentially graded their own homework.

I've been using early access versions of these models for the past few weeks. Sol is genuinely impressive — it handles complex coding tasks with fewer hallucinations than GPT-4. But "fewer" isn't "none," and the gap between demo performance and production reliability is still significant.

The real question nobody's asking

Government approval creates a false sense of security. It tells enterprises "this is safe to use," which in practice means "we can deploy this without worrying."

But AI safety isn't a binary. It's not safe or unsafe. It's a spectrum of behaviors across millions of possible inputs, and a single review can't cover that.

What we actually need:

Continuous monitoring of model behavior in production
Public benchmarks that anyone can run, not just the company
Adversarial testing by independent researchers, not government contractors
Clear liability frameworks for when things go wrong

Instead, we get a stamp of approval that makes everyone feel better while changing nothing about how these models actually behave.

What this means for developers

If you're building with these models (and many of us are), don't let the "government approved" label change your testing strategy. You still need to:

Run your own evaluation suites
Monitor for drift and hallucinations in production
Have fallback mechanisms for when the model fails
Maintain human oversight on critical decisions

I've been using tools like MonkeyCode for code review precisely because I don't trust any single AI model to catch everything. The combination of AI assistance with human judgment and automated checks is still the most reliable approach.

Bottom line

Government safety review for AI models is a good idea in principle. But the current implementation is more theater than substance. It gives enterprises permission to deploy without actually ensuring safety.

The models are getting better. GPT-5.6 Sol is genuinely an improvement. But "better" isn't "safe," and we should stop conflating the two.

Until we have independent, continuous, adversarial testing — not one-time self-reported reviews — "government approved" is just marketing with extra credibility.

What do you think? Does government approval change how you'll use these models?

Discord Banned Thousands by Accident — Why AI Moderation Needs a Human in the Loop

jaryn — Thu, 09 Jul 2026 07:59:07 +0000

Discord just admitted something that should terrify every platform operator: their AI moderation system wrongfully banned thousands of users over harmless images.

The official statement was careful. They called it a "bug." But anyone who has worked in AI safety knows this is not a bug. It is a fundamental limitation of automated content moderation.

The false positive problem

AI moderation systems are trained to catch the worst content. To do that, they cast a wide net. The result: innocent posts get flagged, users get banned, and trust evaporates.

I have seen this pattern across multiple platforms. The AI team sets sensitivity high to avoid missing harmful content. False positives spike. Users complain. The team lowers sensitivity. Harmful content slips through. They raise it again. It is an endless oscillation.

The core issue: AI cannot understand context the way humans do.

A photo of a child at the beach might trigger nudity detection. A medical discussion could flag as graphic content. A meme with dark humor gets classified as harassment. The AI sees patterns, not meaning.

Why this matters for developers

If you are building any platform with user-generated content, you face the same problem. Roll out aggressive AI moderation, and you risk alienating your community. Go too light, and you attract toxicity.

The solution is not better AI — it is better workflow.

This is where tools like MonkeyCode come into the conversation. The platform's approach to AI-assisted work emphasizes a principle that content moderation desperately needs: structured human oversight integrated into automated workflows.

MonkeyCode's architecture keeps humans in the loop. Requirements feed into AI tasks, but verification happens through human review. The AI does the heavy lifting; humans make the judgment calls.

Applied to moderation, this means:

AI flags suspicious content for review
Human moderators make final decisions
The system learns from human corrections
False positives decrease over time

This is not revolutionary. It is common sense. But most platforms skip the human part because it is expensive.

The trust equation

Discord's incident damaged user trust. Users who were wrongfully banned spent days trying to recover their accounts. Some lost years of chat history. Others lost access to communities they helped build.

Trust takes months to build and seconds to destroy.

For platforms, the lesson is clear: AI moderation is a tool, not a replacement for human judgment. The question is not whether to use AI — it is how to structure the workflow so that AI enhances human decision-making instead of replacing it.

Have you experienced wrongful bans on any platform? How did you handle it? Curious to hear other stories.

GPT-5.6 Dropped Three Models at Once — And MonkeyCode Might Be the Missing Piece

jaryn — Thu, 09 Jul 2026 04:22:00 +0000

OpenAI just shipped GPT-5.6 — Sol for the heavy lifting, Terra for volume work, and Luna for everyday use. Three models, one release, full coverage across the price-performance spectrum.

The internet lost its mind for about six hours. Then the takes started rolling in: benchmarks, comparisons, and AGI-is-closer-than-ever threads.

But here is the question nobody is asking: When was the last time a model upgrade actually made your code better?

Sounds cynical, but think about it. We have gone from GPT-3 to GPT-4 to GPT-5, and now 5.6. Each generation is measurably smarter. Yet the day-to-day reality of writing software has not changed that much. The requirements are still vague. The bugs are still sneaky. The only difference is that we now generate bad code faster.

The real bottleneck is not intelligence

A model — any model — is fundamentally an inference engine. It does not know your project structure. It has not read your team style guide. It has zero context about the sprint you are in or the technical debt you are carrying. Every conversation starts from scratch, like onboarding an intern who forgets everything overnight.

This is the gap nobody talks about. AI coding actual bottleneck is not model capability. It is workflow integration.

I have been tracking an open-source project called MonkeyCode that takes this problem seriously. Built by Chaitin, it is not trying to out-benchmark GPT or Claude. Instead, it is building the plumbing:

Cloud dev environments — code, build, test, preview, all server-side. No local setup.
Requirement and spec management — feed structured requirements directly to the AI instead of typing prompts from memory every time.
Team collaboration — shared AI environments where engineering leads can manage workflows centrally.
Mobile support — pick up tasks from your phone. The AI keeps running when you leave your desk.
Private deployment — run it inside your corporate network. Data never leaves.

None of this sounds glamorous. But it is exactly what is missing.

The industry has a pattern

Every time a new model drops, the hype cycle spins up. Everyone gets excited for 48 hours. Then they go back to their actual workflow — which, for most people, means opening a ChatGPT tab, pasting code in, and copy-pasting the response back.

A model is an engine. A platform is a car. You do not throw away the steering wheel and brakes just because you got a V12.

So yes, GPT-5.6 is impressive. Sol benchmark numbers are real. But the question worth asking is not how does Sol compare to Claude. It is: Is your team AI workflow actually ready to use it?

That answer matters more than any leaderboard.

What is your current AI coding workflow? Are you still in chat-and-copy-paste mode, or have you built something more structured? Curious to hear what is working for others.

Agentjacking: A New Attack Targeting Claude Code and Cursor — Could Open-Source Tools Like monkeycode Help?

jaryn — Wed, 08 Jul 2026 07:25:22 +0000

Agentjacking: A New Attack Targeting Claude Code and Cursor — Could Open-Source Tools Like monkeycode Help?

Researchers recently disclosed a new attack class called Agentjacking that targets AI coding agents like Claude Code and Cursor. The technique, reported by The Hacker News, exploits trust in external services connected through the Model Context Protocol (MCP).

How it works

The attack works by poisoning error reports sent to services like Sentry. When the AI agent reads the fake error report, it sees markdown-injected instructions disguised as legitimate diagnostic guidance. The researchers claim an 85% success rate in getting agents to execute malicious code.

What makes this especially nasty is that it bypasses traditional security controls. The agent is not being exploited through a buffer overflow or a stolen credential. It is being tricked through a channel it implicitly trusts: a third-party error-tracking service.

Why MCP security matters now

MCP has become the default way for AI agents to connect to tools, databases, and APIs. That is great for capability, but it also means every connected service becomes part of the attack surface.

If you are running an agent that can read GitHub issues, query your database, and deploy code, a compromise in any one of those channels is potentially a full compromise.

My questions for the security community

Should MCP servers require authentication by default?
How do we sandbox AI agents so that a poisoned prompt cannot exfiltrate credentials or modify production?
Is the answer better prompts, better classifiers, or simply fewer permissions?

Could open-source tools change the trust model?

This is where I think open-source platforms like monkeycode become interesting. Because the project is AGPL-3.0 and self-hostable, teams can inspect how it connects to external tools, control the sandbox, and limit what any single agent is allowed to do. It is not a silver bullet, but it gives operators visibility that closed SaaS agents do not.

Have you started thinking about MCP and agent security? What controls are you putting in place?

Source: The Hacker News — Agentjacking Attack, summarized via Crescendo AI News

OpenAI's Axios Supply Chain Compromise: Why monkeycode's Open-Source Model Matters

jaryn — Wed, 08 Jul 2026 07:14:31 +0000

OpenAI's Axios Supply Chain Compromise: Why monkeycode's Open-Source Model Matters

OpenAI published a detailed incident report about a supply chain attack that affected its macOS app-signing workflow. A compromised version of Axios, a popular HTTP library, was executed in a GitHub Actions pipeline that had access to OpenAI's macOS certificate and notarization material.

The impacted apps include ChatGPT Desktop, Codex App, Codex CLI, and Atlas. OpenAI says there is no evidence that user data was accessed or that malware was signed, but the company is treating the certificate as compromised and rotating it. Users need to update to newly signed versions by May 8.

The technical root cause

OpenAI identified two misconfigurations in the affected GitHub Actions workflow:

It used a floating tag for Axios instead of pinning to a specific commit hash.
It did not configure minimumReleaseAge, which would have delayed automatic adoption of the newly published malicious package.

These are common mistakes. The incident is a good reminder that build pipelines are an attractive target because they sit between source code and published binaries.

The trust problem with closed-source desktop apps

When you download a signed macOS app, you are trusting the entire pipeline that produced it: dependencies, CI configuration, signing keys, notarization service, and the vendor's incident response. Most of that is invisible to the user.

OpenAI handled this transparently, but the fact remains: users had no way to inspect or verify the build themselves.

Why I am watching monkeycode

This kind of incident is why open-source AI platforms like monkeycode are interesting. It is an AGPL-3.0 project that can be self-hosted, meaning teams can audit the code, control the build environment, and avoid relying entirely on a vendor's certificate chain.

That does not eliminate supply chain risk, but it shifts control. For teams with strict compliance requirements, that is a meaningful difference.

Takeaways for security teams

Pin dependencies by commit hash in CI/CD workflows.
Use minimumReleaseAge or similar delays for newly published packages.
Monitor build pipeline access to signing material.
Have a certificate revocation and rotation plan before you need it.

If you are using OpenAI's macOS apps, update now. And if you are evaluating AI development platforms, it is worth comparing the trust models of closed SaaS products and open-source alternatives like monkeycode.

Fable 5 Is Back: A Security-Focused Look at Anthropic's Safeguards and Trade-offs

jaryn — Wed, 08 Jul 2026 06:52:34 +0000

Fable 5 Is Back: A Security-Focused Look at Anthropic's Safeguards and Trade-offs

Anthropic redeployed Claude Fable 5 and Mythos 5 on July 1 after a two-and-a-half week suspension. For anyone working in security or AI tooling, the post is a useful case study in how frontier model deployments can be derailed by a single bypass report.

The timeline

June 9: Fable 5 and Mythos 5 released.
June 12: US government export controls applied after Amazon researchers found a safeguard bypass. Anthropic suspended access globally.
June 26: Government approved Mythos 5 access for some US Glasswing partners.
June 30: Export controls lifted.
July 1: Fable 5 restored globally on Claude Platform, Claude.ai, Claude Code, and Claude Cowork.

The bypass was not unique to Fable 5

The Amazon report described a prompt that caused Fable 5 to identify software vulnerabilities and, in one case, produce code demonstrating how to exploit one. Anthropic's follow-up testing found that many other models could do the same thing, including Claude Opus 4.8, GPT-5.5, and Kimi K2.7. Even the exploit demonstration was reproducible across the entire model family Anthropic tested.

This matters because the incident was framed around Fable 5, but the underlying behavior was not uniquely Mythos-class. The real issue was that Fable 5's safeguards let a borderline case through.

What Anthropic changed

Anthropic trained a new safety classifier targeting the specific bypass. They claim it blocks the technique in over 99% of cases. Blocked requests are redirected to Opus 4.8 with a user notification.

The cost is more false positives. Fable 5 already launched with the largest safety margin Anthropic has ever used, deliberately blocking benign requests to avoid missing harmful ones. The updated classifier tightens that margin further, which means more legitimate coding and debugging requests will get blocked too.

Industry implications

The post also outlines two longer-term efforts:

A shared jailbreak severity framework with Amazon, Microsoft, Google, and other Glasswing partners. The goal is a common standard for judging how serious a given bypass is.
Deeper US government collaboration on pre-release testing, information sharing, and research.

For security teams, the takeaway is that deploying frontier models is no longer just a model-evaluation problem. It is a supply-chain, policy, and incident-response problem.

One open-source alternative to watch

If your team is evaluating AI development platforms but needs something self-hostable and open-source, MonkeyCode is worth adding to the list. It is built around cloud dev environments and team workspaces, and the repo is available under AGPL-3.0. It is not a replacement for Claude, but it is a different deployment model worth understanding.

Source: Anthropic — Redeploying Fable 5