Show HN:AIP Protocol–Solving the agent revocation problem in distributed systems

I realized something uncomfortable while running agents in production:

APIs authenticate the process making a request.

But with LLM agents, the process no longer decides the request — the model does.

So when an agent is prompt-injected or misaligned, authentication still succeeds. The system verifies who executed the call, not who chose it.

Rotating keys or adding revocation checks doesn’t fix this. You’re still trusting the wrapper while the decision lives inside the model.

The missing primitive isn’t stronger identity — it’s verifying the action itself.

In a typical backend system:

service → calls API auth verifies which process made the call

This works because the process contains the decision logic.

With agents:

model decides the action → process just executes it

So authentication still proves who called but no longer proves who decided

If an agent is compromised (prompt injection, tool misuse, leaked context), rotating API keys or checking revocation lists doesn’t actually solve the problem — the system still trusts the process identity while the decision authority lives inside the model.

What we needed was verification of the action itself.

I built a small protocol where every side-effect requires a signed “intent”.

Each agent has a keypair. Every tool call carries a signature over:

action

parameters

timestamp

nonce (replay protection)

declared capabilities

Verification is local (Ed25519, <1ms). Services don’t call an auth server — they verify the intent.

Revocation is async: services subscribe to key invalidation events, but verification still works offline.

Example:

from aip_protocol import shield

@shield(actions=["read_db","send_email"]) class SupportAgent: def handle_ticket(self, ticket_id): ...

If the agent attempts an undeclared action, the call is rejected before execution.

Tradeoffs:

more complex than API keys (key management)

doesn’t stop prompt injection, only limits consequences

requires thinking in capabilities instead of identities

I’m trying to figure out if this is actually a missing primitive for agent systems or unnecessary complexity.

Repo: https://github.com/theaniketgiri/aip

Spec: https://github.com/theaniketgiri/aip/blob/master/RFC-001.md

Would especially like feedback from people running agents beyond demos.