How Aembit Helped a $300B Investment Firm Secure AI Agent Access

Facebook X-twitter Instagram Linkedin Whatsapp

AI assistants can make it much easier to find information across a company. But once an assistant can reach financial research, email, or internal files, a basic question comes up: how do you know what it can access, and who is responsible for what it does?

A case study from Aembit offers one example. An unnamed investment firm secured its Claude assistants for more than 500 people using agent-aware access controls, short-lived credentials, and audit logs. Here’s how the setup works, what the firm says it achieved, and what other businesses can take from it.

Why AI agents need an identity of their own

When someone asks an AI assistant to find information or use a connected service, the assistant may act on that person’s behalf. The employee has an identity in the company’s access system, but the agent may act using that employee’s identity and access rights without a distinct way to identify the agent itself.

That can create a few headaches. An agent might rely on a broad or shared credential that gives it more access than it needs. And if something goes wrong, the security team may have a hard time tracing what happened.

In its case study, Aembit says the investment firm wanted to give more than 500 employees access to Claude, including connections to financial research, email, calendars, SharePoint, and Microsoft 365. Before expanding access, the firm needed a way to control those connections and keep a clear record of agent activity.

How the access controls work

Aembit’s approach checks two identities: the employee using the assistant and the agent making the request. That means an access decision can take into account both the person and the specific AI agent they’re using.

When an agent requests access to a connected service, Aembit evaluates the request using the employee’s identity and the agent’s identity. Its MCP Gateway enforces access policies in real time and handles token exchange, while its MCP Authorization Service issues blended-identity tokens. Instead of storing long-lived credentials in Claude or MCP server configurations, Aembit issues short-lived, policy-scoped tokens for the required access. The system also logs tool invocations and attributes activity to the employee and agent.

According to Aembit, the firm kept Okta for employee identity and sent agent activity logs to CrowdStrike for security monitoring. That meant the rollout could build on systems the company already used.

What the case study reports

According to Aembit’s case study, the deployment secured more than 500 users in two weeks, with 100% of agent actions logged and auditable. Aembit also says the deployment required less than 6 hours of security team time.

Those numbers offer a sense of the rollout’s speed and coverage, but they come from Aembit, the vendor. The public case study does not name the investment firm or provide independent validation of the reported results, incident-reduction figures, or detailed cost savings. It is therefore best read as a practical example of one enterprise deployment, rather than evidence that the approach prevents every AI security problem.

How a business can put agent access controls in place

It’s easy to see why companies are exploring this. AI agents can help employees work across company information and connected tools. But that access needs limits, accountability, and a straightforward way to shut it off when needed.

A business could start small and build up in steps:

  1. Choose one useful task. Pick a specific workflow, such as letting a research assistant retrieve approved internal reports. Keep the first use case focused so it’s easier to assess what access the agent actually needs.
  2. Map the data and tools. List the reports, services, and systems the task requires. Connect the agent through existing identity systems and APIs, and set rules for which employees and agents can reach each resource.
  3. Limit access and keep a record. Give the agent only the permissions needed for the task. Log each request so the company can see which employee and agent accessed which resource. Keep a person involved in sensitive actions, such as sending information outside the company or changing records.
  4. Run a small pilot. A startup could begin with a few analysts and a read-only workflow. They might ask an assistant to find information in approved reports. Once the team has reviewed the access decisions and audit records, it can decide whether to add more users or tools.
  5. Test, train, and measure before expanding. Try realistic misuse scenarios, train employees on approved workflows, and decide who will review logs and access policies. Track how long agent approvals take, what share of actions can be traced to both a person and an agent, how often requests are blocked, and how quickly access can be revoked. These measures help teams see whether oversight is improving without making everyday work cumbersome.

The opportunity: Make it easier to use AI safely

For founders and business leaders, there’s room to build around the identity and access needs that come with AI agents. Companies want assistants that can work with their systems. They also need to know which agent accessed which resource, on whose behalf, and whether the request was allowed.

Begin with one useful workflow. Give the agent only the access it needs, and make its actions easy to review. As adoption grows, that combination of employee confidence and security-team visibility can become a real advantage.

Come back to AI Opportune for more practical stories about AI in business, and subscribe to stay up to date.

You May Also Like

Leave a Reply

Your email address will not be published. Required fields are marked *