This week's GitHub vulnerability is not a surprise. It's the architecture that no one should have used in the first place.
On July 8, SecurityWeek reported that researchers at Noma Labs found a critical prompt-injection flaw in GitHub Agentic Workflows. I've been talking about this for almost two years. Don't use 3rd-party agents that you don't control. You've ceded the non-deterministic, the stochastic, the however you want to say it - the part you don't control - to the whims of another system. That is not a reasonable architecture in today's world.
The flaw is being called GitLost. The mechanics are quite simple: an unauthenticated attacker opens an issue in a public repository, hides instructions inside it, and waits. A workflow triggered on issues.assigned reads the issue, and because that agent runs with read access to both public and private repos, it follows the buried instructions and posts private repository contents back as a public comment.
This attack doesn't require any technical knowledge or backdoor access. GitHub's guardrails were in place, and they failed (as they often do); the researchers got past them by adding a single word - "additionally." This is why we cryptographically sign agents, so that we rely on mathematical enforcement and not wishful words.
As Noma put it: the agent's context window is also its attack surface. Anything the agent reads can be weaponized.
Never put the non-deterministic part of your automation - the agent, the thing that reasons, interprets, and decides - outside your visibility and control.
The moment you do, you've accepted a bargain that no security team should ever knowingly agree to.
The contractor you'd never actually hire
Think about what outsourcing an agent really is. It's like hiring a contractor to work on your most sensitive company data, except:
- You don't know and didn't run background checks on this contractor.
- You have no control over what they do once they start.
- You can't review what they accessed or what they did with it.
- You're implicitly trusting that some third party always gave them the right instructions, that they always interpreted those instructions correctly, and that they always handled your data with the same care you would.
- And if something goes wrong, you have no way to audit what happened, no way to see what they touched, no way to perform remediation, and no way to quickly fix it and keep the critical business systems that now depend on this automation running.
I hope you wouldn't blindly hire that 3rd-party contractor. Yet that is exactly the deal when you let an agent living in someone else's org reach into your systems. GitLost is what that contractor looks like on a bad day: following a stranger's instructions, with your private repos in hand, in public.
The employee you actually want
Now do it the other way. Use your own in-house, security-conscious agents. This is like hiring your own employee:
- They're vetted.
- They're trained on your best practices.
- There are consequences for their actions and the results.
- You control what systems they access and, broadly, what they do with that data.
- When they mess up, and agents, like people, do, it becomes a learning opportunity. You have total visibility into what happened. You can provide additional training and perform remediation.
Every one of their touchpoints to the outside world goes through deterministic, well-defined, well-controlled, limited access points. Everything stays completely automatable. The difference is where the non-determinism lives: in-house, performed by an agent you trained, or at least one you can relatively trust and should completely control.
The only thing that should leave your walls is an API call
Here's the part people keep getting backwards.
API endpoints are among the most secure, absolutely deterministic, well-defined methods ever built for accessing and modifying data in other systems. They have contracts. They have scopes. They have auth, rate limits, and audit logs. They do exactly what they say and nothing else.
That is precisely what you want crossing your boundary.
An agent is the opposite. It's non-deterministic by nature. It reasons over whatever lands in its context, including a booby-trapped GitHub issue, and decides what to do next. Putting that on the far side of your control boundary, as the thing that reaches into your data, is backwards. Using agents in other systems as endpoints is architecturally unreasonable. Use the deterministic thing, the API, as your endpoint, and keep the non-deterministic thing, the agent, at home.
What "in-house" should actually look like
Keeping agents in-house shouldn't mean giving up any of the leverage that made you want agents in the first place. In NuDay, security-conscious agents are things you can start, stop, modify, clone and share, and organize into working groups, all from a centralized control plane. That same plane inherently encrypts any data the agents touch and save.
That last part is the difference between an incident and a catastrophe. When an in-house agent makes an "oopsie," the blast radius is already far more limited and contained because the data is encrypted by default, access is scoped, and you can see exactly what happened and roll it back. When an external agent makes the same mistake, you find out from a security researcher's blog post.
The question (not) to ask
So the question isn't "how do I secure my third-party agents." It's a bit more nuanced than that:
Why would you ever enable a third-party agent to do whatever potentially random things with your systems or data?
Automate everything. Move fast. But keep the reasoning inside your walls, put your agents under one control plane, encrypt by default, and let only deterministic, well-defined API calls cross the boundary. Anything else is architecturally unreasonable, and GitLost is just the latest reminder of why.
NuDay makes agentic AI provable and audit-ready: encrypted data, separated identities, cryptographically enforced tools, and tamper-evident audit, built in, not bolted on. See the proof.