SecureLore

A lore to keep admin stress-free for a better agentic workspace

Comment

Inspiration

Building a Slack agent is becoming fast. Approving one is not.

A builder can assemble an agent, connect an MCP server, request OAuth scopes, and deploy AI behavior in a short sprint. The workspace admin receiving that app still has to answer a much harder set of questions: What can it access? Why does it need each scope? Which actions can it take? What happens to Slack data? Is its AI behavior disclosed? What evidence supports the builder's claims? Has the artifact changed since somebody approved it?

Today that handoff is usually scattered across messages, screenshots, manifests, policy documents, and one-off meetings. A generic chatbot can explain a scope, but it cannot create a durable approval process. It does not bind a decision to the artifact that was reviewed, preserve finding-specific evidence, enforce reviewer authority, or remember a team's accepted policy lessons.

SecureLore was inspired by that trust gap. We wanted to turn agent approval from an informal conversation into a Slack-native review room where builders and admins can move from "this should be safe" to a version-bound, evidence-backed decision.

What it does

SecureLore is a Slack-native preflight and approval agent for Slack applications, AI agents, and MCP-enabled workflows.

A builder starts from SecureLore's Agent view or runs /securelore review. They submit an official Slack app manifest, an optional MCP tools/list response, and structured context describing the app's visible features, public pages, AI model and retention behavior, scope justifications, consequential actions, human-review controls, and runtime evidence.

SecureLore turns those inputs into a review packet inside Slack:

  • A clear risk grade with blockers and warnings
  • A scope table that connects permissions to user-visible behavior
  • MCP tool analysis covering descriptions, side effects, and destructive actions
  • Checks for production HTTPS endpoints, public pages, and AI disclosures
  • A remediation plan that tells the builder what must change
  • An admin brief that summarizes the decision instead of dumping raw JSON
  • A canonical SHA-256 fingerprint for the exact artifact under review

The packet opens into a Review Room. Each finding has its own evidence trail, so a builder can attach a justification, runtime proof, or corrected artifact to the issue it is meant to resolve. SecureLore scores evidence for relevance, specificity, testability, and policy alignment. Narrative evidence can clarify a sensitive permission, but it cannot erase an artifact-level blocker such as an insecure endpoint. That boundary prevents persuasive text from bypassing a real defect.

When a builder submits a corrected artifact, SecureLore compares it with the previous version and shows what was resolved, what remains, and what is new. The new artifact receives a new fingerprint. Any earlier approval becomes stale, ensuring an admin never appears to approve code or permissions they did not actually review.

SecureLore also includes a Workspace Evidence Scout powered by Slack Real-Time Search. A user can ask for precedent such as Find workspace precedent: files:read approval. SecureLore searches only Slack content that user is permitted to access, returns citations to the original messages, and keeps the result zero-copy: it is not persisted, embedded, used for training, or silently converted into approval evidence. RTS is load-bearing because the decision can be informed by fresh workspace context without building a shadow copy of Slack history.

Once blockers are resolved, the builder requests admin review. SecureLore posts the fingerprinted packet to a configured approval channel. Only explicitly authorized reviewers can approve or reject it, and an approval cannot be recorded while blockers remain. The decision is attached to the exact artifact fingerprint.

Finally, teams can promote a deliberately sanitized lesson from a completed review. SecureLore embeds that lesson and retrieves it during similar future reviews. This is product memory, not model training: raw RTS results are never stored, review evidence remains review-specific, and only an explicit sanitized lesson enters retrieval memory.

The complete workflow stays inside Slack: intake, workspace precedent, findings, evidence, remediation, corrected versions, reviewer handoff, decision, learning trace, history, and self-service deletion.

How we built it

SecureLore is a TypeScript workspace with Slack as the product surface and Vercel as the production runtime.

Slack-native experience

Slack Bolt handles request verification, slash commands, events, modal submissions, Block Kit actions, App Home, and the Agent/Assistant conversation. The Agent view gives first-time users a guided entry point, while /securelore review provides a fast command-driven path. Review packets, Review Rooms, scope tables, patch plans, learning traces, and approval controls are rendered with Block Kit.

Real-Time Search without a shadow data store

Workspace Evidence Scout calls Slack's assistant.search.context method with the short-lived action token delivered by the user interaction. Search is user-triggered, public-channel scoped, permission-aware, and citation-first. Search responses are rendered directly back to Slack and are never written to SecureLore's database.

Deterministic review intelligence

The review-core package performs deterministic checks across OAuth scopes, endpoint security, public app pages, AI disclosures, MCP metadata, consequential actions, human controls, runtime evidence, and optional workspace policy. Deterministic checks establish the safety boundary; OpenRouter adds explanations and remediation suggestions without being allowed to override blockers.

Every submission is canonicalized and hashed. The fingerprint covers the manifest, MCP tool list, and structured review context, which lets SecureLore detect artifact drift and invalidate stale decisions.

Evidence and retrieval memory

Neon Postgres stores review sessions, generated artifacts, finding-specific evidence, feedback, human decisions, policy chunks, and promoted lessons. pgvector supports semantic retrieval. Cohere creates embeddings for policy and sanitized lesson retrieval. Tenant boundaries keep workspace memory isolated, and App Home includes self-service deletion for a user's review data.

Human governance

Reviewer authorization is configured with Slack member IDs rather than broad admin.* permissions. A dedicated Slack channel receives approval requests. This preserves a sandbox-installable core while still demonstrating a real builder-to-admin handoff. Optional workspace policy can prohibit scopes, require reviewer attention, or demand specific runtime proof.

Production and trust pages

Vercel hosts the signed Slack request endpoints and the Next.js landing, privacy, and service-status pages over HTTPS. The privacy page explains model providers, retention, retrieval learning, RTS zero-copy behavior, deletion, and the commitment not to train language models on Slack data.

Challenges we ran into

The first challenge was resisting the temptation to solve this as another manifest linter. A list of warnings is useful, but the business problem is the handoff between the person building an agent and the person accountable for allowing it into a workspace. That led us to add Review Rooms, finding-specific evidence, corrected-artifact lineage, reviewer authorization, and fingerprint-bound decisions.

The second challenge was using workspace context without violating Slack's privacy model. Copying channel history into a vector database would have made retrieval straightforward, but it would also create a shadow store of Slack data. Real-Time Search gave us a better architecture: retrieve fresh context only when a user asks, preserve Slack's access controls, cite the source, and store nothing from the response.

The third challenge was separating learning from training. Review feedback is valuable, but silently feeding raw Slack data into a model would undermine the trust SecureLore is supposed to create. We designed an explicit promotion step where a user writes a sanitized lesson. Only that lesson enters workspace-scoped retrieval memory.

The fourth challenge was balancing administrator value with sandbox installability. Slack's organization administration APIs require elevated installation models that would make the hackathon experience harder to test. SecureLore therefore uses a reviewer allowlist, a dedicated approval channel, submitted artifacts, and optional workspace policy without requesting broad admin scopes.

The final challenge was Slack's interaction timing. Slack expects actions and modal submissions to be acknowledged quickly, while policy retrieval and model enrichment can take longer. SecureLore acknowledges the interaction first, posts an immediate progress message, and completes the review asynchronously through the production runtime.

Accomplishments that we're proud of

We are proud that SecureLore is a complete decision workflow rather than a chatbot wrapped around policy text.

  • The core experience is native to Slack from first prompt to final approval.
  • Real-Time Search contributes fresh, permission-aware workspace precedent without creating a second Slack archive.
  • Evidence belongs to individual findings and is evaluated against explicit quality dimensions.
  • Artifact defects cannot be dismissed with narrative justification.
  • Corrected versions are compared with their parents, and every material change invalidates the old approval.
  • Human decisions are fail-closed: unresolved blockers and unauthorized reviewers cannot approve an app.
  • Admins receive a concise approval packet in a dedicated channel instead of reconstructing context from a long thread.
  • Teams can build workspace-specific review memory through explicit, sanitized lessons without training an LLM on Slack data.
  • Users can see review history and delete their stored review data from App Home.
  • The public privacy experience explains the same data boundaries that the product enforces.

Most importantly, each technical component supports the product promise. RTS supplies live precedent. Fingerprints protect decision integrity. Neon preserves the audit trail. Cohere retrieves policy memory. OpenRouter improves explanations. Bolt and Block Kit keep the workflow where builders and admins already collaborate.

What we learned

We learned that trust in workplace agents is not produced by one risk score. It comes from preserving the chain between the submitted artifact, the policy finding, the evidence, the corrected version, the authorized reviewer, and the final decision.

We learned that fresh context is more useful when it remains under the source platform's permissions. Real-Time Search allowed SecureLore to answer "has our workspace handled this before?" without copying messages into another system.

We also learned that organizational memory needs an explicit editorial step. Raw feedback is noisy and may contain sensitive information. A promoted lesson should be intentional, sanitized, scoped to the workspace, and visible in the learning trace that influences later reviews.

Finally, we learned that security tooling becomes easier to adopt when it helps both sides. Builders receive specific remediation instead of a vague rejection. Admins receive a concise, reviewable packet instead of raw implementation details. SecureLore is designed to shorten that distance without weakening the decision.

What's next for SecureLore

The next step is to make SecureLore a reusable policy layer across an organization's agent lifecycle.

  • Policy drift alerts when Slack guidance or an organization's own requirements change after approval
  • Scheduled re-review when scopes, endpoints, MCP tools, AI providers, or retention behavior change
  • Cryptographically exportable approval receipts for change-management and audit systems
  • Organization-managed policy packs for security, privacy, legal, and accessibility teams
  • Runtime evidence adapters that verify deployment health, request signing, and declared data boundaries
  • Aggregate, privacy-preserving reporting on recurring blockers and remediation patterns
  • Additional Slack surfaces for reviewing agent changes directly from deployment and release workflows

Our long-term goal is for SecureLore to become the trust layer between "an agent was built" and "this agent is ready for our workforce."

Architecture Diagram

SecureLore architecture

The diagram follows the product journey from builder intake through review intelligence, live workspace precedent, evidence-backed remediation, fingerprint-bound admin approval, and explicit retrieval learning. It also makes the core trust boundaries visible: Slack request verification, zero-copy RTS, human-gated decisions, tenant-scoped storage, and no LLM training on Slack data.

Built With

Share this project:

Updates