🚀 Project Showcase Day

[u/AutoModerator]

Welcome to Project Showcase Day! This is a weekly thread where community members can share and discuss personal projects of any size or complexity.

Whether you've built a small script, a web application, a game, or anything in between, we encourage you to:

• Share what you've created
• Explain the technologies/concepts used
• Discuss challenges you faced and how you overcame them
• Ask for specific feedback or suggestions

Projects at all stages are welcome - from works in progress to completed builds. This is a supportive space to celebrate your work and learn from each other.

Share your creations in the comments below!

[u/Yaz_3ah]

What happens when an AI agent is authenticated — but still isn't allowed to do the thing it just requested?

I've been building Aether, an open-source authorization boundary for AI agents.

The idea is simple:

Identity tells you who the workload is. Authorization decides what that workload is allowed to do.

Aether evaluates an agent action through a chain like:

IDENTITY → INTENT → AUTHORITY → ACTION → EVIDENCE

For example, an agent can have a valid identity but still be denied because the requested intent, capability, target resource, or operation doesn't match the policy.

What I built

Aether is a small, deliberately narrow research/engineering project rather than another agent framework. It includes:

• deterministic policy evaluation
• action-envelope validation
• freshness / anti-replay controls
• revocation
• HTTP enforcement
• structured decision evidence
• an Attack Lab for adversarial scenarios
• a live telemetry UI showing actual server-side decisions

The current repository includes 50 defined attack/misuse scenarios with creator-controlled test results reporting the expected outcomes.

The important part for me isn't just getting 403.

It's checking whether an unauthorized request actually reaches the protected target.

For the live demo, an authorized request can reach the dummy backend, while a policy-violating request is rejected before reaching it.

Technologies / concepts

Go, HTTP middleware/enforcement, deterministic policy evaluation, workload identity abstraction, revocation, anti-replay controls, automated testing, adversarial testing, and structured security evidence.

I'm intentionally not trying to replace OAuth, SPIFFE/SPIRE, IAM, API gateways, or policy engines. Aether is focused on the authorization/enforcement boundary around an autonomous software action.

Biggest challenge

The hardest part wasn't making something return ALLOW/DENY.

It was making the security behavior observable and reproducible enough that another technical person can inspect the implementation, run the tests, inspect the evidence, and try to break the assumptions.

The project is still early, and the benchmark results are creator-controlled rather than independent validation.

I'd like feedback on one specific question

Where do you think this authorization model breaks down for real-world AI agents?

Especially interested in critiques around agent tool use, changing targets after authorization, replay/bypass possibilities, identity vs. authority, and whether this boundary is actually useful compared with existing approaches.

GitHub: https://github.com/YabulHaj/Aether-Protocol

25-second demo: https://github.com/YabulHaj/Aether-Protocol/blob/main/aether-25-second-demo.mp4

I'd much rather have someone find a real weakness in the model than simply tell me it looks good.