{"slug": "try-to-hack-my-ai-agent-workflow-github-issues-as-a-control-surface", "title": "Try to Hack My AI-Agent Workflow: GitHub Issues as a Control Surface", "summary": "Public experiment where users can submit GitHub Issues to request an AI-agent workflow to create a static demo page on the author's website, with the explicit challenge to try bypassing the system's boundaries. The author's serious goal is to explore whether external user intent can be safely integrated into a real product repository as a bounded, reviewable change without ceding product ownership. The experiment emphasizes that the key outcome is not the generated page itself, but the visible trace of the workflow's decision-making, including correct rejections, which demonstrate the agent's ability to defend product boundaries.", "body_md": "I built a small public experiment.\nYou can open a GitHub Issue and ask an AI-agent workflow to create a static page on my website:\nAnd if you want to make the experiment more interesting, do not only submit a valid request. Try to bypass the boundary. Try to make the workflow publish something it should not publish. Then inspect the issue comments, labels, pull request, and final result.\nThis is the game.\nBut under that game, there is a more serious question:\nCan external user intent enter a real product repository and become a bounded, reviewable product change without giving up product ownership?\nThat is what I am trying to explore.\nThe public playground is here: Demo Pages\nThe surface rule is simple:\nCreate a GitHub Issue that requests a small static demo page.\nThe workflow should read the issue, decide whether the request belongs to the allowed area, run the required agent steps, create or update the page, validate the result, and publish it only if the process succeeds.\nBut this is not a public CMS.\nIt is not a hosting service.\nIt is not a website builder.\nIt is not a place where an external user should be able to change my homepage, global layout, styles, scripts, product pages, or site structure.\nThe allowed result is intentionally narrow: a bounded inert static page under the Demo Pages section.\nSo the challenge has two sides.\nFirst, try the normal path:\nCreate a small demo page request and see whether the workflow can turn it into a published static artifact.\nThen try the adversarial path:\nAsk for something outside the boundary and see whether the workflow stops you.\nFor example, you can try to request a homepage change, inject instructions into the issue body, ask the agent to modify global styles, or try to smuggle forbidden behavior into the generated content.\nPlease keep the challenge inside the intended boundary. This is a workflow and prompt-boundary experiment, not an infrastructure attack. Do not attack the server, credentials, network, GitHub itself, availability, or anything outside the issue text and the public repository workflow.\nThe interesting question is not whether the server can be broken.\nThe interesting question is whether a chain of AI agents can defend a product boundary while still allowing useful delegated work.\nThe workflow is intentionally public enough to leave evidence.\nA request should not disappear into a private chatbot.\nA useful result should leave a visible trail:\nThe page itself is not the main artifact.\nThe main artifact is the trace.\nA static page is only the visible end of the process. The more important part is the path from external request to controlled product change.\nIf the workflow accepts your request, you can inspect what happened.\nIf the workflow rejects your request, you can inspect why.\nA successful rejection is also a useful result.\nIn ordinary automation, a rejection often feels like failure. In an AI-agent workflow, a correct rejection is evidence that the process has boundaries. It means the agent did not blindly satisfy the user request. It treated the issue as a signal, not as a command.\nThat distinction matters.\nAI coding agents are getting better at producing code.\nBut code generation is not the hardest part of using agents in real products.\nThe harder problem is control.\nIf these questions are not answered, “autonomous agent development” easily becomes an uncontrolled prompt playground.\nThat may be interesting for demos, but it is not how I want agents to touch real products.\nIn a product environment, the owner must not lose control. Users can express intent. Agents can perform delegated work. But the product owner must define the paths where autonomous work is allowed, the boundaries where it must stop, and the evidence required before the result enters the product.\nThis experiment uses static demo pages because they are safe, visible, and easy to understand.\nBut the real subject is not static page generation.\nThe real subject is controlled product evolution.\nA user opens an issue. The workflow checks whether the request belongs to an approved path. If it does, agents may process it. If it does not, the request should be rejected, blocked, or routed to human review.\nThat is the model I want to test in public.\nThe current experiment uses GitHub Issues as the entry point.\nA GitHub Issue is a familiar development artifact. It can describe a request, collect discussion, receive labels, trigger events, and preserve history. That makes it a practical control surface for agent-driven work.\nThe simplified route looks like this:\nThe workflow does not treat the issue as a direct publishing request.\nIt treats the issue as a development signal.\nThat signal must pass through rules.\nFor the Demo Pages experiment, the allowed area is intentionally small. The agent may work only inside the documented demo-page boundary. It must not turn a reader request into arbitrary site changes.\nThis is where the workflow becomes more important than the generated page.\nA simple page-generation demo could be built with one prompt and one script.\nThat is not the point here.\nThe point is to show a controlled route where request admission, agent execution, validation, pull request creation, merge, and publication are separate observable steps.\nThe boundary is not protected by asking the model to “please behave.”\nThat is not enough.\nThe workflow needs several kinds of control.\nFirst, there is a documented scope.\nThe agent must know what kind of request is allowed, what area of the repository may be changed, and what must remain untouched.\nSecond, there is admission.\nBefore implementation starts, the request should be classified. A request that targets the homepage, global layout, scripts, styles, or product content should not be treated as a valid demo-page request.\nThird, there is restricted execution.\nAgents should run in a bounded environment and work through repository changes, not through direct production mutation.\nFourth, there is validation.\nThe result must be checked before it becomes a published artifact.\nFifth, there is evidence.\nLabels, comments, pull requests, and logs matter because they make the process inspectable. Without evidence, autonomy is difficult to trust.\nThis is why I am inviting people not only to submit valid requests, but also to submit boundary-crossing requests.\nA workflow that only succeeds on clean examples is not very interesting.\nA workflow becomes more useful when it can say:\nNo, this request is outside the approved path, and here is why.\nThat answer is part of the product control model.\nThis experiment looks small because the artifact is small.\nA static page is not a large feature.\nBut the pattern is larger than the artifact.\nMany teams already use GitHub Issues, pull requests, CI checks, reviews, and deployment pipelines. AI agents can enter this environment, but they need more than task prompts. They need process boundaries.\nA product team does not only need an agent that can write code.\nIt needs a way to answer:\nThat is the commercial reason I care about this.\nI am not trying to demonstrate that an AI agent can write a static page. That is already obvious.\nI am trying to demonstrate that an AI-agent workflow can transform an external request into a controlled, reviewable, bounded product change.\nFor a real team, this pattern could apply to documentation fixes, small UI corrections, test additions, generated examples, controlled content updates, internal tools, or other well-bounded change paths.\nThe important part is not the specific artifact.\nThe important part is the governance loop:\nintent -> boundary check -> delegated work -> evidence -> review -> product change\nThe public workflow is powered by my GitHub Flows work.\nThe host application is here: github-flows-app\nIt is a ready-to-run host application around @teqfw/github-flows\n. It starts a Node.js process, loads local runtime configuration, exposes the GitHub webhook ingress, provides a workspace for configuration and logs, and allows the workflow runtime to react to GitHub events.\nThe host application itself is not the whole idea.\nThe broader idea is that repository events can drive agent execution through an explicit process. An issue is opened. A label is added. A pull request is created. A validation result appears. A merge happens. These events can move work through a controlled chain instead of relying on one long manual chat session.\nI described the conceptual layer here: Turning User Intent Into Controlled Product Evolution\nThat article explains the model behind this experiment: users express intent, the product owner defines approved paths, agents act as delegated intermediaries, and the product changes only through bounded, observable, reviewable steps.\nStart here: Demo Pages\nTry a simple valid request first.\nThen try a request that should be rejected.\nLook at the labels.\nRead the agent comments.\nFollow the pull request if one appears.\nOpen the published page if the request reaches publication.\nIf the workflow rejects you, that may be the correct result.\nIf the workflow publishes something it should not publish, I want to know.\nAnd if you are working with a real product team and thinking about how AI agents could safely participate in GitHub-based development, I am interested in practical cases.\nThe question is no longer only:\nCan an AI agent write code?\nThe more useful question is:\nCan we give agents limited authority inside a process that product owners can control?\nIf that is the kind of problem you are facing, you can contact me.", "url": "https://wpnews.pro/news/try-to-hack-my-ai-agent-workflow-github-issues-as-a-control-surface", "canonical_source": "https://dev.to/flancer64/try-to-hack-my-ai-agent-workflow-github-issues-as-a-control-surface-4jcf", "published_at": "2026-05-22 09:27:43+00:00", "updated_at": "2026-05-22 09:46:22.997656+00:00", "lang": "en", "topics": ["artificial-intelligence", "cybersecurity", "developer-tools", "open-source"], "entities": ["GitHub", "AI-agent"], "alternates": {"html": "https://wpnews.pro/news/try-to-hack-my-ai-agent-workflow-github-issues-as-a-control-surface", "markdown": "https://wpnews.pro/news/try-to-hack-my-ai-agent-workflow-github-issues-as-a-control-surface.md", "text": "https://wpnews.pro/news/try-to-hack-my-ai-agent-workflow-github-issues-as-a-control-surface.txt", "jsonld": "https://wpnews.pro/news/try-to-hack-my-ai-agent-workflow-github-issues-as-a-control-surface.jsonld"}}