Digital Meld

Today I took part in the first GitHub Secure Open Source Fund "Repository Under Attack" Red Team Workshop, and WON! The exercise dropped us into a simulated software supply-chain incident involving a malicious package, unsafe automation, exposed GitHub Actions secrets, and cross-repository credentials. Our job was to investigate the attack chain, contain it, recover safely, and decide how and when to communicate with maintainers, users, providers, and the public. My team, Porcupine-Forge, came out victorious! Thank you to my teammates for staying sharp and working the problem together. GPT-5.6 Sol in Codex, OpenClaw, and the GitHub Copilot app all came in clutch, but the real advantage was keeping the evidence, decisions, response tasks, and verification tied together while the incident was moving. My biggest takeaway: Even in a simulation, the heart was pounding - and an incident response plan cannot be something you intend to write after an incident. Open source maintainers need clear roles, a trusted source of truth, credential-revocation steps, provider escalation paths, communication templates, and evidence-based closure criteria before they need them. I published a detailed and sanitized after-action report from the simulation is in the comments below. Thank you to GitHub, Gregg Cochran, and the entire Secure Open Source Fund team for making this workshop happen. It was practical, difficult, and genuinely useful. If you maintain an open source project, apply for Cohort 5. The time to prepare for a repository attack is before one happens (link in comments) #Codex #GitHubCopilotApp #OpenClaw #OpenSource #Sol

Microsoft introduced KARS, the Agent Reference Stack for Kubernetes, and the Azure/kars repo is worth reading if you care about agents on the Microsoft stack. KARS stands for Agent Reference Stack for Kubernetes. The name is very platform-engineering, but the business problem is simple: if agents are going to touch real tools, cloud resources, customer data, and business workflows, they need to run like real infrastructure. I was able to see an early working version of KARS as it was being built, and it is good to see Microsoft putting real energy into self-hosted agents across KARS, Microsoft Scout, OpenClaw, the Agent Governance Toolkit, and the other pieces forming around this ecosystem. Most agent demos show the chat window or tool call. Then the questions that matter start showing up: • What identity does the agent use, and what secrets can it see? • Which network paths and tools are allowed? • What gets audited, and what requires human approval? • What happens when the agent is wrong or compromised? Those are production questions. KARS matters because the repo starts from that access problem. The architecture puts the agent in a hardened sandbox, keeps credentials out of the agent process, and brokers external calls through a Rust inference router. That router becomes the policy point for identity, safety signals, budgets, rate limits, egress rules, MCP calls, governance, audit, A2A, and encrypted mesh traffic. In plain English, the agent is not the trust boundary. The runtime is. That gets more useful when KARS is paired with the broader Microsoft agent stack. OpenClaw gives builders and operators a runtime and command surface. Microsoft Foundry gives teams model access and safety signals. Codex can turn repo work into issues, branches, PRs, checks, and reviewable changes. Microsoft Scout points toward the always-on assistant pattern. AGT brings policy, audit, identity, trust, and SRE controls into the stack. For business use, that points to some practical patterns: • Field operations: read job context and draft updates without roaming the whole network. • IT/SRE: diagnose alerts while approval and execution stay gated. • Finance and support: use sensitive data without breaking separation of duties or account boundaries. • Software delivery: use OpenClaw, Codex, GitHub, and KARS so changes stay scoped, reviewed, and verified. The caveat matters: KARS is an open-source reference implementation, not an officially supported Microsoft product. I would treat it as an architecture signal and evaluation target, not something to drop blindly into production. Agents are becoming long-running, tool-using, network-reaching applications. KARS brings that conversation back to ground Microsoft shops already know: AKS, Entra, Foundry, GitHub, policies, logs, approvals, and runbooks. Start small, think big, and please do not give the bot admin because the demo was cool. (more in comments below)

Microsoft just committed $2.5 billion and 6,000 people to their Frontier Company, a new AI implementation unit built around embedded engineering, industry knowledge, change management, and measurable business outcomes. Satya Nadella framed the future of the firm as a "learning loop" where human capital and token capital compound. Microsoft also made a point that matters: a company's proprietary data, workflows, expertise, and decision-making have to be protected, not commoditized. I am glad to see the biggest AI companies getting more honest about this. THE MODEL IS NOT ENOUGH! AI adoption in business is personal. Every company has its own workflows, trust issues, source-of-truth problems, spreadsheet kingdoms, quiet workarounds, tribal knowledge, and people who know why the official process is not the real process. You do not learn that from a demo. You learn it by sitting with the business long enough to understand how the work actually moves. That is why we have never liked calling the companies we work with "customers" at Digital Meld. They are partners. A customer buys something from you. A partner builds something with you. That difference matters. The job is not to force a business into a tool stack. The job is to learn the business, understand the people, and fit the software, workflows, automations, and AI around them. We have seen the same pattern over and over. A team asks for AI, but the first useful fix is intake. A leader wants reporting, but the real problem is that finance and operations use different definitions of the same status. A department wants an agent, but nobody has written down the judgment calls their best employee makes every day. A company wants automation, but the source of truth is still a spreadsheet everyone complains about and everyone secretly trusts. AI can help with all of that, but only if the business is willing to do the people work first. A model can summarize a process document. It cannot know whether that document reflects reality. A model can draft a workflow. It cannot know whether the field team will actually use it. A model can generate a dashboard. It cannot fix trust in the underlying data. There is no turnkey solution for real AI adoption. OpenAI, Anthropic, Microsoft, Amazon, and the consulting world are all moving toward hands-on implementation because the hard part is no longer access to a model. The hard part is making AI useful inside the messy, human, specific reality of a business. My advice to leaders is boring, but it works: • Start with one workflow that hurts. • Find the people who live with it. • Map the real process, not the aspirational one. • Identify the source of truth. • Decide where AI should help, where it should stay out, and where a human must approve. • Verify the result with the people who will use it. Then repeat. That is the learning loop that matters. AI should be shaped around your people and your business, not the other way around. Start small, think big.

Before a business rolls out Codex, it needs a boring answer to a practical question: what should the agent be allowed to access for this task? Over the weekend, I saw OpenAI's Tibo Sottiaux call out the new Codex permissions work with a line that gets to the point: "Least privilege per task." He also described it as a replacement for "coarse sandbox modes," which lines up with the problem I keep running into when agent work moves from personal usage to team usage. For personal work, broad access can feel harmless because you know the machine, the repo, and the risk. A business cannot rely on that. The team needs clear answers on what Codex can read, what it can write, whether it can reach the internet, whether it can see environment files, and when a human needs to approve the next step. I turned the Codex permissions docs into a small SOP for my own setup: • read for reviews, audits, planning, and explanation work • work for normal repo implementation inside the workspace, without network access • work-net for work that needs docs, package managers, GitHub, public APIs, or browser smoke tests • :danger-full-access only when the task has a real reason, like release/signing work, machine cleanup, multi-repo maintenance, or a sandbox-proven blocker The labels make the access decision visible before the work starts. Review-only work does not need write access. A normal implementation task usually does not need network. Docs, packages, GitHub state, and browser proof belong in a different mode. Full local access needs a reason before the run starts. For business teams, most useful work sits between "no agent access" and "all agent access." Let Codex edit the workspace. Deny secrets. Scope network. Keep release, signing, and machine-level cleanup behind stricter rules. That gives builders speed while giving reviewers and security-minded people a policy that lives in files. The docs make this more than a prompt convention. Permission profiles can bind file read/write/deny rules, network rules, and built-in or custom profiles. I put the SOP in AGENTS .md, put the profiles in config.toml, and verified the setup with codex --strict-config doctor. Start small, think big: review, implement, implement-net, release. Give each mode the access it needs. Widen only when the work proves it. ** full code snippets and more context via the article in the comments. **

I read Google's Kaggle whitepaper, "The New SDLC With Vibe Coding," by Addy Osmani, Shubham Saboo, and Dr. Sokratis Kartakis, and the most useful part for my Codex workflow was not the phrase "vibe coding." It was the harness. The paper makes a practical point that is easy to miss when everyone is arguing about which model is best: the model is only part of the agent. The useful system around it is the harness: instructions, tools, sandboxes, guardrails, memory, evals, and observability. That maps almost perfectly to the way Codex work either succeeds or wastes time. When Codex does a good job, it is usually because the harness is clear: • the repo has useful instructions • the task has a real target • the agent can inspect the actual code path • the verification command is known • the handoff says what changed and what was checked • risky work has boundaries When Codex or GPT 5.5 do a bad job, I try not to blame the model first. More often, the task was underspecified, the context was stale, the wrong files were loaded, the verifier was missing, or I let the agent loop without a clean stop condition. In plain English: if you want better Codex output, do not start by writing cleverer prompts. Start by building a better work surface. For me, that means every serious Codex task should carry a few boring fields: • Mode: prototype, standard, or production • Context: the repo, issue, source doc, or files that matter • Boundary: what can change and what cannot • Verification: the exact command, browser check, smoke test, or rubric • Handoff: what changed, what passed, and what risk remains That is not as exciting as saying the agent can "build the whole thing." It is also a lot closer to how useful work ships. The caveat is important. This does not remove human judgment. It moves human judgment earlier in the process. You decide the mode. You decide the boundary. You decide what "done" means. Codex can move fast inside that box, but someone still has to build the box. My practical takeaway from the whitepaper: treat your Codex setup like part of the software system, not like a chat window. The prompt, the repo instructions, the tools, the tests, and the handoff are not administrative overhead. They are the harness. **example prompt can be found in the article link in comments** That is the difference between asking an agent to be magic and giving it a system to operate inside. A loose prompt can produce a convincing diff. A good harness produces a diff, a reason, a boundary, a check, and a handoff. That is the part I think matters most. **another example prompt can be found in the article link in comments** The future of coding agents is not just better models. It is better working surfaces around the models. The sooner you realize that, and put it into action, the better your results will be. Start small, think big. #Codex #OpenClaw #AgenticAI #AIAgents

Over the weekend I used OpenClaw and Codex to build and deploy a Power Apps Code App for a client. The interesting part was not just the build. It was how I used the tools and kept the business context from getting lost. I started in OpenClaw because it already had the long-running context: spreadsheets, workflow notes, call transcripts, project history, source-system notes, and the small decisions that usually disappear before implementation starts. Those months and months of context mattered more than any single prompt. OpenClaw helped shape the first version of the Dataverse schema JSON, the Mermaid Entity Relationship Diagram (ERD), and the workflow map. OpenClaw brings clarity to chaos. Then I moved into Codex with GPT-5.5 on Extra High. The first pass was a design-standards Markdown file based on a reference UI and the client's design-language docs. After that I added the Power Platform and Dataverse MCPs, CLIs, and skills so Codex was working inside the actual platform constraints. Then I used /plan. Codex read the repo, schema, ERD, reference exports, design standard, and Microsoft docs. The result was the Project Requirements Document (PRD) I wanted to build from. After that, I used Matt Pocock's grill-with-docs skill to challenge the PRD: source of truth, schema drift, route parity, access control, Dataverse boundaries, deployment gates, and what belonged in v1. The best habit in the whole workflow was saving prompts as Markdown files: • /plan prompt • issue-generation prompt • implementation /goal prompt That kept the project from depending on chat history, and it gives my teammates and their agents a clear record of how the app was built. Once the PRD was ready, Codex generated GitHub issues. Each issue included intent, files/routes, Dataverse tables, dependencies, acceptance criteria, non-goals, and verification steps. Implementation became a simple loop: take the next unblocked issue, branch, build the smallest useful PR, run the check, merge, sync main, and continue. The final Dataverse contract ended up at 89 tables, 1,148 columns, and 156 relationships. I did not create those manually. Codex did it with the Dataverse MCP and Power Platform CLI. This is a game changer. Verification stayed part of the work: schema validator, lint, build, Playwright checks, screenshots where useful, and explicit Power Platform deployment gates. The split worked because each tool had a clear job. #OpenClaw carried the business context, using months of hard work between my team and the client team to understand their business. #Codex turned that context into repo files, issues, PRs, checks, and deployment notes. For client work, that matters. The app is important, but the context is what lets another developer or another agent pick it up later without starting over. Your process and planning is far more important than the model you choose. Start small, think big. Want more? Read the full article on my X. Link below. #AIAgents #AgenticAI

Most people still use coding agents like fancy autocomplete or a one-shot chat box. That leaves a lot of value on the table. The better pattern is to treat Codex like a durable operating loop: • persistent threads for long-running workstreams • disk-backed notes for memory you can inspect and diff • browser surfaces for real visual review • small HTML apps instead of dead Markdown when interaction matters • automations for follow-up loops • clear verification before calling anything done The big shift is this: Codex should not just answer prompts. It should keep work moving across surfaces. A useful Codex thread can inspect a local app, open a static artifact, check a rendered slide deck, watch a PR, update project notes, and come back with something reviewable. That is a very different workflow from "generate code and stop." I use looping for helping to maintain OpenClaw, and build and support my own opensource projects, like Veritas Kanban, and to develop software and solutions for my clients at Digital Meld. At any given time, I have more than a dozen loops running in Codex. Still have doubts? You don't have to take my word for it. OpenAI's Jason Liu inspired this post, and I've seen first-hand the power of loops with OpenClaw and 🦄 Peter Steinberger's superhuman workflows. Want to see how I instruct Codex with loops? Click through to the link in the comments to grab the markdown... and get your loop on. Start small, think big. #Codex #OpenClaw #AgenticAI #AIAgents #Loops