Why Axec
An agent that can only talk is a chatbot, but once it acts on a real system it needs credentials, someone has to decide what it may do with them, and your security team needs a record of what it did. Axec is the access control plane for agents connecting to enterprise MCP servers and APIs. It handles all three outside the agent, so developers ship without rebuilding them and security teams review, restrict, and revoke access in one place, whether it is the first agent or the fiftieth.
The agent authorization problem
Section titled “The agent authorization problem”Agent authorization means deciding, when an agent acts, whether this agent may do this action, in this system, for this person. Ordinary applications have fixed code paths, so a sign-in and a set of OAuth scopes are enough to describe what they will do. An agent chooses its actions at runtime from a model’s output, and untrusted content such as an email can steer that choice. A support agent may read a ticket and then update a customer record, but those actions need different permissions.
Whose authority the agent should use also varies:
- Alex asks a coding agent to open a pull request, so it acts with Alex’s access and nothing broader.
- A scheduled agent reads shared tickets overnight, so it uses limited access of its own, never Alex’s accounts.
- An assistant prepares Alex’s morning summary after he has logged off, so it continues only what Alex approved earlier.
Coarse credentials cannot express this. A send scope allows any message to anyone, a stored credential can leak through prompts and logs, and an approval can outlive the user’s intent. Closing the gap takes four checks on every request: which agent is calling, whose authority it uses, what that authority permits right now, and whether a human must approve first.
How Axec solves it
Section titled “How Axec solves it”Axec keeps those four checks separate and enforces them outside the agent, so the agent never holds the credentials or makes the final decision.
- Recognize the Application
- Check its permitted access
- Apply policy and required review
- Use the approved credential
Blocked requests do not reach the service.
A User's approved account or access configured for automation.
A person approves or denies the exact request when policy requires it.
Records show decisions and outcomes. Optional risk assessment adds context, not permission.
- Connect. Give each agent its own identity and a governed path to your systems, acting for the person using it, for itself, or for someone who has stepped away.
- Protect. Keep credentials in Axec, so agents receive results instead of secrets.
- Control. Check access and policy on every request, and require approval for sensitive actions.
- Prove. Record who asked, whose access was used, and what was decided and executed.
| Concern | Handled inside each agent | With Axec |
|---|---|---|
| Credentials | Tokens and API keys live in agent code | Credentials stay in Axec; the agent receives only results |
| Permissions | Whatever the stored token allows | Per-request policy on top of what the user approved |
| Sensitive actions | A chat confirmation, if anyone remembered to add it | Approval bound to the exact request |
| Background work | Reuses a person’s token or a shared key | Runs on limited access of its own, and can be revoked |
Connect systems and define agent access
Section titled “Connect systems and define agent access”Connectors describe enterprise services, MCP gateways bring selected tools together, and each agent has an Application identity separate from the person it works for. People sign in with your existing login, such as Okta or Microsoft Entra ID, and scheduled jobs use access of their own. Authorization Modes explains how to choose between them.
Protect credentials and broker their use
Section titled “Protect credentials and broker their use”Axec stores supported credentials encrypted and uses the approved account to run MCP and HTTP requests, keeping secrets out of the model’s context. Some flows release a limited token for direct use; Axec controls the release but not later direct calls, so keep execution through Axec when you need request-level controls. Security Architecture covers these limits.
Control every action
Section titled “Control every action”Axec checks current access and policy on each request, so revoked approval or changed permissions stop later operations. Policies can block actions or require review, but never expand access. When human review is required, approval is bound to the exact request, the authenticated client must retry it, and it can go to a team of reviewers, such as your support leads.
Prove what happened
Section titled “Prove what happened”Axec records which Application acted, whose access it used, and the decision and outcome, without retaining credentials or unrestricted payloads. Data Protection can mask sensitive results, and optional risk assessment flags unsafe tool use for investigation without approving or denying anything.
Where to go next
Section titled “Where to go next”If you build agents, start with the Quickstart and then the Guides. If you operate or review Axec, read How Axec works and Security Architecture. The Concepts explain the underlying identities and permissions.