Agentic Security

How to Build Secure Agent Memory and a Company Brain

Build a secure company brain for agent memory that prevents secret leakage. Use scoped access control, human-in-the-loop approvals for durable knowledge updates, and delegated authorization to ensure coding agents act only with the permissions of the responsible user.

MMichael SwindellSeptember 9, 202616 min read

A secure company brain is a shared, evolving knowledge system that gives people and coding agents access to useful organizational context without exposing information they are not entitled to see. It can include policies, technical decisions, customer knowledge, operational procedures, and project history. The hard problem is not storing the knowledge. It is enforcing access rules every time an agent retrieves context or takes action. A system such as Levr helps teams connect agent work to shared project context, acceptance criteria, verification, and accountability. The practical goal is simple: make useful knowledge reusable while keeping sensitive data scoped, reviewable, and attributable.

At a Glance

A company brain should grow through reviewed contributions, not silently collect everything.

Core risk: Shared knowledge can expose sensitive finance, HR, customer, and operational information when access boundaries are weak.
Best structure: Use one interconnected knowledge base with access scopes on each page or document.
Safe updates: Let agents propose knowledge changes, but require a person to approve the facts and audience.
Critical control: Retrieve context and execute tools using the requesting user’s permissions, not a broadly privileged agent identity.
Operational outcome: A visible audit trail makes knowledge sharing safer and easier to improve over time.

What is a company brain, and why does it create security risk?

A company brain combines shared context with access to data and tools that help people and coding agents complete work. It becomes risky when broad retrieval, autonomous memory writes, or reusable credentials allow an agent to reveal or act on information beyond a user’s actual permissions.

The phrase can describe many implementations: a linked wiki, markdown files in a repository, a knowledge graph, or an internal system that retrieves information for an agent. The storage format matters less than two questions:

Who can read a specific piece of context?
Who can make changes or invoke connected tools?

Consider an employee responding to a customer security questionnaire. The agent needs approved security material, not compensation information, private legal discussions, or unrelated customer records. A new employee may need onboarding guidance but should not inherit broad visibility simply because they can query the same assistant.

This is why a company brain is not just a search index. It is an access-control system, a knowledge-maintenance system, and, when agents can take actions, an execution-security system. A pile of markdown files won't scale either, the structural fix is covered in building an AI-powered knowledge base for production agents.

The OWASP Top 10 for Large Language Model Applications identifies prompt injection and excessive agency among the major risks facing LLM-enabled systems. Those risks become concrete when an agent can ingest untrusted content, query private systems, or perform write operations on behalf of users.

Why should you grow a company brain instead of trying to build one?

A useful company brain emerges from everyday work because no central team can accurately document every decision, exception, and workflow across an organization. The people solving a problem should be able to contribute relevant knowledge with minimal effort and clear ownership.

A large, one-time documentation program tends to decay before it becomes valuable. Organizations change too quickly. Teams make technical decisions during incidents, customer calls, planning sessions, and code reviews. The highest-value context is often produced while resolving a specific problem, not while filling out a generic knowledge template months later. Left unmanaged, this kind of shared memory can decay the same way any second brain does, see how to stop your AI second brain from rotting.

A healthy system can become more active as trust grows. Once people see that contributions help others answer questions, investigate incidents, or complete recurring work, they have a reason to teach the system more. Knowledge compounds:

A team documents how to query a system.
Someone adds how to interpret the query result.
A later contribution records the safe action to take from that result.
Corrections and edge cases improve the original guidance.

That growth only works if adding knowledge is lightweight. Requiring every contributor to manually edit a repository, choose file locations, create pull requests, and wait for a separate review flow will discourage participation. At the other extreme, allowing agents to silently write memory creates opaque and potentially dangerous context.

The workable middle ground is an agent-generated proposal that a person can accept, revise, scope, or reject in the flow of work.

How should access control work in a shared knowledge system?

Access control should apply to each knowledge object and every retrieval request. An agent must read context using the claims of the person who requested help, so it can only return information that person could access directly.

A companywide knowledge base does not mean every employee can read every page. It means the organization avoids creating disconnected team memories that prevent useful knowledge from being reused across the business.

Use linked documents or pages as the shared structure, then assign scopes to each one. Scopes may represent teams, functions, projects, roles, or other approved groups. For example:

Company-wide: Product principles, engineering standards, public technical architecture, and general operating procedures.
Engineering: Service ownership, incident playbooks, deployment guidance, and internal architecture notes.
Finance: Financial planning, revenue details, and budget processes.
HR: Employee-sensitive guidance, performance processes, and compensation information.
Project-specific: Customer commitments, implementation decisions, and restricted operational details.

The critical implementation detail is runtime enforcement. The agent should not retrieve all available content and attempt to hide sensitive details afterward. It should query only the pages that match the requesting user’s verified permissions. Filtering after retrieval is a weak boundary because the model may already have received the restricted data.

The NIST AI Risk Management Framework Playbook emphasizes governance, documented processes, and risk controls throughout an AI system lifecycle. Scoped retrieval and traceable authorization checks put those principles into daily agent operations.

Why should agents suggest knowledge updates instead of writing memory automatically?

Agents should propose updates because automated memory creates an unreviewed record of facts, interpretations, and permissions. Human approval keeps the knowledge base accurate, assigns responsibility, and lets contributors choose the right scope before sensitive or misleading context spreads.

An agent can still reduce the work substantially. After resolving an issue, answering a security questionnaire, or diagnosing an incident, it can identify reusable facts and produce a concise suggested update. The person involved does not need to decide where every paragraph belongs. They need to review whether the information is correct and who should be able to use it.

A practical approval flow

Complete the work: Resolve the request, incident, customer question, or technical investigation.
Generate a proposal: Have the agent identify durable facts, decisions, commands, caveats, and links worth preserving.
Review the content: Confirm that the proposed knowledge is accurate, current, and not overly broad.
Set the scope: Choose who can read or modify the knowledge entry.
Record ownership: Attach the approving person’s identity and preserve the change history.

This pattern is less burdensome than treating every knowledge contribution like a formal documentation project. It is also much safer than treating agent memory as a trusted source of truth.

Every accepted change should identify a human owner. An agent can draft it, classify it, and place it in the right connected location, but it should not be the final accountable author. When a fact becomes stale, a scope is too broad, or an incident exposes a weak process, the organization needs to know who approved the entry and when.

Secure Agent Memory at Scale

The Levr Dashboard unifies your project context, issues, and active agent activity into a single control plane. By keeping coding agents connected to documented acceptance criteria and verified test results, you ensure that every memory update is attributable, scoped, and human-approved.

Agentic Software Development | Control Plane | Manual & Automatic Verification Issue Tracking |Levr

Use the Levr Dashboard to manage agent access and review durable knowledge updates across your team.

Give coding agents context with visible controls.

Levr keeps issues, acceptance criteria, tests, agent activity, and human approvals in a shared control plane so work remains connected to the evidence needed to verify it.

Explore agent-first workflows with Levr

How do shared agents handle incidents without privilege escalation?

Shared agents can support collaborative incident work when each tool call uses the permissions of the responsible user. Credentials should never sit broadly available in an agent sandbox, where one conversation participant could accidentally or deliberately gain another person's authority.

Collaborative incident response is where shared context becomes most valuable. A group may need to inspect logs, examine code, identify a regression, prepare a pull request, deploy to staging, update monitoring, and potentially approve production deployment. The discussion itself can produce high-quality organizational knowledge, especially when people uncover an undocumented technical decision or correct an earlier assumption.

However, the people participating do not necessarily share the same authority. An engineer may investigate logs and create a branch. A release manager may approve deployment. A security lead may authorize access to a sensitive system. A shared agent must preserve these boundaries.

Use delegated credentials at the execution layer

Do not place long-lived, broadly privileged credentials inside an agent environment. Instead, proxy or virtualize access to protected tools and inject the authenticated user’s authorization at the HTTP, SQL, or equivalent execution layer.

In practice, this means:

The agent receives a request from an authenticated user.
The system determines that user’s claims and permitted actions.
Tool calls are made through a controlled service or proxy.
The proxy applies the user’s authorization to each request.
The audit trail records the user, the agent action, the target system, and the outcome.

This model limits privilege escalation. An agent helping an engineer debug a query cannot independently transform that access into permission to deploy production changes. It can coordinate the work, preserve context, and prepare the next step, while the authorized person remains responsible for the action.

What does a secure company brain workflow look like in practice?

A secure company brain workflow separates intent, retrieval, proposed knowledge, execution, and approval. Each stage has a clear owner, applies the right permissions, and records what happened so teams can reuse knowledge without granting agents unchecked autonomy.

Take a customer security questionnaire as an example. A customer asks about data practices, security controls, and technical architecture. An employee asks an agent for help preparing a response.

Define the request: The employee asks for answers to the questionnaire and identifies the relevant customer context.
Retrieve scoped knowledge: The agent searches only approved security, product, and customer information available to that employee.
Create a draft: The agent prepares answers and identifies gaps or claims requiring confirmation.
Require human review: The employee checks the draft before sharing it externally.
Propose reusable knowledge: If the work revealed a missing or improved answer, the agent suggests a knowledge-base update.
Approve and scope the update: A responsible person confirms the facts, selects access scopes, and becomes the recorded owner.

The same pattern applies to engineering work. In Levr’s agentic workflow, teams define intent in natural language, let agents take on tasks, use automated verification, and retain human review and approval. Issues, test evidence, and work history remain connected rather than disappearing into separate prompts or isolated agent sessions.

Which company brain mistakes create the biggest security and adoption failures?

The biggest failures come from treating knowledge as either fully open or fully automated. Broad access leaks secrets, disconnected team memories create silos, and silent agent writes make it impossible to trust what the system knows or why it knows it.

Building a giant all-at-once knowledge project: This delays value, creates stale documentation, and assigns the wrong people responsibility for domain knowledge.
Expecting manual shared-skill maintenance: Most employees will not maintain technical knowledge files for unknown future users after completing demanding work.
Creating separate team brains: Per-channel or per-team memory often becomes another silo that cannot help the wider organization.
Giving every agent a broad service account: This turns a useful assistant into a high-impact access path for sensitive systems.
Allowing automatic memory writes: Unreviewed facts and scopes can become persistent, invisible sources of error or data exposure.
Using prompt instructions as the only guardrail: Prompts are not a substitute for least privilege, access enforcement, sandboxing, and audited execution.
Failing to preserve attribution: Without a human approver and change history, teams cannot responsibly correct or investigate knowledge failures.

The design principle is straightforward: put reusable context in one connected system, apply scoped access to every object, require humans to approve durable memory, and execute actions through the permissions of the responsible user.

Technical Deep Dive FAQ

What is a company brain?

A company brain is an internal knowledge system that connects organizational context to people and agents doing work. It may contain policies, architectural decisions, customer information, operational procedures, project history, and reusable guidance. Unlike a static wiki, a company brain is often designed for retrieval by coding agents or shared assistants. That makes access control essential. The system must decide what context a particular user can retrieve and what actions they can perform through connected tools.

What is the difference between a company brain and a knowledge base?

A knowledge base is usually a collection of documents intended for people to browse or search. A company brain adds agent-oriented retrieval, connected context, and sometimes the ability to use tools or take actions. That extra capability makes it more useful for workflows such as incident response, customer questionnaires, and engineering tasks. It also increases risk because an agent may combine information from multiple sources or interact with protected systems. A secure design therefore needs document scopes, runtime authorization, and auditability.

Can a company brain use markdown files?

Yes. Markdown files can work well because they are portable, linkable, readable by people, and easy for agents to process. The important issue is not whether knowledge lives in markdown, a wiki, or a graph database. The system must support document-level access scopes, revision history, and permission-aware retrieval. A simple shared folder without those controls can expose sensitive documents. A markdown-based company brain should also preserve the relationships between pages so agents can navigate related context without receiving unrelated private material.

How do you prevent an AI agent from leaking confidential information?

Prevent leakage by enforcing authorization before context reaches the agent. The agent should retrieve documents using the requesting user’s verified claims, not a global index or a privileged system identity. Limit each document to the appropriate groups, apply least privilege to connected tools, and require human approval for persistent knowledge updates. Avoid relying on instructions that tell the model not to reveal secrets after it has already seen them. Structural access controls are more dependable than prompt-only controls.

Why is automatic agent memory dangerous?

Automatic memory is dangerous because it stores information without confirming whether it is correct, sensitive, durable, or appropriately scoped. An agent may mistake a temporary workaround for policy, preserve an incomplete incident theory, or write confidential details into a broadly accessible memory store. Over time, these entries become difficult to discover and correct. A safer model has the agent propose a concise memory update, then lets a responsible person review the facts, choose the access scope, and approve the change with their name attached.

What is delegated authorization for coding agents?

Delegated authorization means an agent performs a retrieval or tool call under the authenticated permissions of the person responsible for that request. The agent does not hold a permanent credential that grants broad access to databases, deployment systems, or internal services. Instead, a controlled execution layer validates the user’s claims and applies them to each action. This supports collaboration without flattening privileges. An engineer can investigate within their approved access, while a production deployment still requires the authority and approval of an authorized operator.

Should agent credentials be stored in a sandbox?

No. Storing broadly privileged credentials in an agent sandbox creates a high-risk escalation path. The sandbox may process untrusted text, external content, tool output, or injected instructions. If credentials are available there, a compromised or confused agent can potentially use them beyond the intended task. Keep credentials outside the sandbox and mediate access through a proxy, gateway, or execution service that applies per-user permissions. Record each action so teams can audit who initiated it, what the agent attempted, and what happened.

How should teams capture knowledge from incident response?

Capture incident knowledge after the team has established the actual cause, decision, and corrective action. Agents can identify candidate lessons from logs, investigation notes, code changes, and discussion threads, but people should validate the final entry. The most useful record usually explains the failure mode, how to detect it, the approved fix, and any constraints that prevent recurrence. Avoid saving early speculation as durable truth. Scope the record appropriately, especially if it contains customer, security, or infrastructure-sensitive details.

How can an engineering manager measure whether a company brain is healthy?

Measure whether people are actively using, correcting, and extending the knowledge system as part of normal work. Useful signals include approved updates, recurring questions resolved through existing context, time to find operational guidance, unresolved knowledge gaps, and the age of high-value entries. A growing volume of reviewed contributions may indicate trust, but raw document count is not enough. Engineering managers should also track access-control exceptions, rejected update proposals, stale content, and whether agent activity remains attributable to a human or agent identity.

Can Levr support a secure agentic engineering workflow?

Levr provides a shared control plane for teams where humans and coding agents work on the same projects, issues, tests, and workflow states. Agents can use structured acceptance criteria, update work in the same system, and record test activity alongside the issue being implemented. Levr also attributes actions by human or agent and supports quality gates before work reaches completion. For teams coordinating Claude Code, Cursor, Codex, Copilot, and other MCP-compatible tools, this keeps project context and verification connected to execution.

Key Takeaways

A secure company brain is a governed system for shared context, not an unrestricted memory store.

Grow, do not build: Capture reusable knowledge from real work instead of attempting a one-time documentation program.
Keep one connected source: Avoid isolated team memories, but scope every page and retrieval request.
Approve durable changes: Agents should suggest knowledge updates while humans validate content, scope, and ownership.
Delegate authority: Execute retrieval and tools using the responsible user’s permissions, never a broad sandbox credential.
Preserve accountability: Record who approved knowledge and who initiated each agent action.

Useful shared context and strict security controls are compatible when the system treats identity, scope, and approval as first-class parts of the workflow.