Inspiration

AI agents can now send messages, modify files, call APIs, update records, and trigger business workflows. However, most approval systems only record that a human clicked Approve. They do not always guarantee that the action executed afterward is the exact action the human reviewed.

An agent could request approval for one action and then change the destination, parameters, content, resource, or tool before execution. A valid approval could also be replayed, reused, or executed after being revoked.

Consentry was built around one principle:

One approval. One exact action. One time.

Instead of treating approval as a simple button click, Consentry turns it into a cryptographically verifiable authorization artifact.

What it does

Consentry is a consent-integrity firewall for AI agents operating through Slack.

Before an agent performs a sensitive action, Consentry creates an exact action contract containing:

Workspace Requester Approver Agent identity Tool and action Resource and destination Parameters Content digest Policy version Expiration time Unique token identifier

The action contract is converted into canonical JSON and cryptographically fingerprinted. When a human approves the request in Slack, Consentry issues a signed, time-limited, single-use consent token bound to that exact fingerprint.

At execution time, Consentry reconstructs the proposed action and verifies that it still matches what the human approved.

Execution is denied when:

The payload was modified after approval The token was already consumed The token was revoked The approval expired The signature is invalid The execution context does not match Required authorization evidence is missing

Consentry fails closed: no valid consent evidence means no execution.

The demo includes four security scenarios:

An approved action executes successfully. A modified action is blocked with CONSENT_HASH_MISMATCH. Reusing the same token is blocked. A revoked token is denied with TOKEN_REVOKED.

A browser dashboard displays live metrics, token state, execution decisions, and the tamper-evident audit trail.

How we built it

We built Consentry as an authorization layer rather than a traditional approval bot.

The Slack experience uses Block Kit to display the action contract and collect approval or rejection decisions. Slack Socket Mode receives interactions without requiring a public development endpoint.

The backend uses:

FastAPI SQLite Signed consent tokens RFC 8785-style canonical JSON Cryptographic payload fingerprinting Atomic one-time token consumption Token expiration and revocation Tamper-evident audit chaining MCP integration

For every protected action, Consentry generates a deterministic representation of the complete action contract. Its cryptographic digest becomes the approval boundary.

During execution, the digest is recalculated from the action actually being attempted. Even a small change to the destination, content, parameters, resource, or action causes verification to fail.

We also built an MCP server so AI agents and tool-calling systems can request consent and verify authorization before performing protected operations.

Challenges we ran into

One of the biggest challenges was deciding exactly what an approval should authorize.

Binding approval only to a tool name or action type was not enough. Approving send_message, for example, would be unsafe if the agent could later change the recipient or message content. We therefore had to include the complete security-sensitive context in the action fingerprint.

Canonicalization was another challenge. Cryptographic hashing only works reliably when logically identical payloads always produce the same byte representation. Differences in key ordering or serialization could otherwise create different hashes. We addressed this using deterministic canonical JSON.

Replay prevention required more than token expiration. Two execution attempts could potentially validate the same token before either marked it as used. We implemented atomic token consumption so only one execution can successfully claim a token.

Revocation also required server-side state. A token may have a valid signature but still need to be rejected because its authorization was withdrawn.

Finally, we wanted security failures to be visible rather than hidden in backend logs. The dashboard and repeatable attack demonstrations make payload substitution, replay, and revocation failures easy to understand.

Accomplishments that we're proud of

We are proud that Consentry demonstrates enforceable consent integrity rather than only displaying an approval prompt.

The project includes:

Exact approval-to-action binding Deterministic contract hashing Signed and expiring consent tokens Atomic single-use enforcement Explicit token revocation Payload-substitution detection Replay prevention Tamper-evident auditing Slack-native approvals MCP integration A live browser dashboard Automated security tests

The project demonstrates both successful authorization and adversarial failure paths. It proves that modified, replayed, revoked, expired, and invalid actions are blocked.

What we learned

We learned that human approval and secure authorization are not the same thing.

An approval interface captures intent, but an enforcement layer must preserve that intent through execution. Without cryptographic binding, the approved request and the executed request can become two different objects.

We also learned that agent authorization must include context. The agent, requester, approver, workspace, destination, resource, parameters, policy version, and expiration can all affect whether an action should be permitted.

Replay prevention must also be stateful and atomic. A signed token alone is not sufficient when authorization is intended to be used exactly once.

Most importantly, AI-agent security should not depend on trusting the agent to remember what was approved. The authorization layer must independently verify the action at execution time.

What's next for Consentry

The next step is to develop Consentry into a reusable authorization layer for production AI-agent systems.

Future capabilities include:

Risk-based approval policies Multi-approver and quorum authorization Step-up approval for high-risk actions Approval delegation with strict scope limits Enterprise identity-provider integration Asymmetric and hardware-backed signing Key rotation and centralized key management Distributed storage for scaled deployments Additional MCP and agent-framework integrations SIEM and security-orchestration integrations Administrative policy management Anomaly and abuse detection Formal action-contract schemas

The long-term vision is for Consentry to become a universal consent boundary between autonomous AI agents and the systems they can affect.

This human approved this exact agent, performing this exact action, under these exact conditions, one time.

Built With

  • agent-security
  • ai-agents
  • audit-logging
  • authorization
  • cryptography
  • css
  • cybersecurity
  • fastapi
  • hmac
  • html
  • identity-security
  • javascript
  • json
  • mcp-server
  • model-context-protocol
  • pytest
  • python
  • rest-api
  • sha-256
  • slack-api
  • slack-block-kit
  • slack-socket-mode
  • sqlite
  • uvicorn
  • zero-trust
Share this project:

Updates

Submission history