We built a security gate for Git pushes. Then we gave it a memory.

One of the most annoying things about security issues in a project is that you can fix the same type of problem more than once.

You find a vulnerability.

You fix it.

A few days later, something similar happens again.

And your security tool starts from zero.

That was the idea behind SecurePush.

We wanted to build something that could sit in the normal Git workflow and check code before it gets pushed, but we also wanted it to remember what happened in previous reviews.

That is where Hindsight came in.

So what is SecurePush?

SecurePush is basically a security gate for git push.

Instead of pushing code directly to the remote repository, SecurePush checks the changes first.

The flow is pretty simple.

You make your changes.

You run:

git push

SecurePush picks up the changed files and reviews them for security issues.

If it finds something, it explains what is wrong and suggests a fix.

You can accept the fix or reject it.

If you accept it, SecurePush applies the change and runs the checks again.

If everything passes, the push continues.

If there is still a problem, the push is blocked.

Simple enough.

But the interesting part comes after that.

What if it remembered?

Let's say SecurePush finds a hardcoded credential in your project.

It tells you about it and suggests moving it to an environment variable.

You accept the fix.

The fix is applied.

The tests pass.

The push goes through.

Normally, that's the end of it.

But we don't want SecurePush to forget that entire interaction.

We use Hindsight to remember it.

Not the actual secret.

The useful information around it.

Something like:

A hardcoded credential was found in scripts.js. The developer accepted the environment variable fix and the tests passed.

Now that information is part of the repository's security memory.

Then comes the second push

Later, you make another change.

SecurePush doesn't just look at the new code.

Before reviewing it, it checks the repository's previous security memory.

It might find that the repository has already had a similar credential issue before.

That context is then given to the security review.

So instead of every review being completely isolated, the agent has some idea of what happened before.

And this is the part we wanted to demonstrate with Hindsight.

First review:

It finds the problem.

The developer makes a decision.

The result gets remembered.

Later review:

A similar situation comes up.

The previous decision can be recalled.

The current code is still checked normally, but now there is some history behind the review.

We also wanted the memory to be visible

We didn't want Hindsight to just be something hidden in the backend that we mention during the presentation.

So we added a Memory section to SecurePush.

It shows what the repository has remembered from previous security reviews.

You can see things like the type of issue, the file involved, what the developer decided, whether the fix worked, and other relevant information.

The idea is simple.

You should be able to see what the system remembers instead of just being told that it has memory.

There was one important problem

If SecurePush is supposed to find secrets, we obviously can't just store those secrets in its memory.

So before something is retained, sensitive values are removed.

We want to remember:

A hardcoded credential was found and the developer moved it to an environment variable.

We don't want to remember:

API_KEY = "actual-secret"

That was an important part of building the memory layer properly.

The complete flow

So the final workflow looks like this:

Code change

↓

git push

↓

SecurePush scans the changes

↓

Previous security memory is recalled

↓

Security issue is found

↓

Developer accepts or rejects the fix

↓

Fix is applied and verified

↓

Push is allowed or blocked

↓

The result is remembered

And the next review can use that memory.

What we actually found interesting

For me, the interesting part wasn't just getting an LLM to find a security vulnerability.

There are already plenty of tools that can do that.

The interesting part was seeing what happens when the system doesn't forget every interaction.

A normal security scan can tell you what is wrong with the code right now.

With memory, the system can also have some context about what happened in the repository before.

That opens up a lot of possibilities beyond SecurePush too.

Repositories have a lot of history.

Why a certain decision was made.

Which fixes were tried.

Which security issues kept coming back.

What the team accepted or rejected.

A lot of that knowledge normally stays scattered across commits, issues, chats, and people's heads.

We wanted to see what happens when some of that knowledge can actually be remembered and used during the next interaction.

That's what we built with SecurePush.

**A security gate that doesn't just check your code.

It remembers what happened before.**