/security
Security
This page details our security principles and standards: the technical controls built into every agent we build, and our guidance for the parts that depend on people.
This page describes how we build. It is not a certification or a compliance attestation.
At a glance
- Where it runs: our gateway and tools, serverless, in an isolated AWS environment of its own for each client. Cloud systems need nothing installed at the client. On-prem systems get one small tunnel connector that connects outbound only.
- Where the model runs: in the client's own chat client for work people start; through Amazon Bedrock in the client's AWS environment for fully autonomous agents.
- What we hold: credentials for the service accounts you create, encrypted with a separate key per client. Never admin accounts.
- Who decides access: the client's identity provider decides who can call which tools. Your service accounts decide what those tools can do.
- What's logged: every tool call. The action, not the data.
- How to cut us off: disable the service accounts. Every tool that uses them stops right away.
Technical controls
Where things run
Each client is a tenant, and each tenant gets its own isolated AWS environment. We call that environment a frame: a separate AWS account that we set up and run for that client alone, on serverless infrastructure. Nothing is shared between frames, so a problem in one client's environment can't reach another's. We host the gateway and tools there. Cloud systems need nothing installed at the client. Our tools, and any vendor connectors we put behind our gateway, reach them the way any cloud app does: through each system's API, signed in as a service account you created.
For systems on the client's own network, like an on-prem SQL database or a file share, we install one small connector on that network: Cloudflare Tunnel (cloudflared). It makes an outbound-only, encrypted connection, so nobody opens an inbound firewall port. Traffic passes through Cloudflare's network on its way to our tools, and the tools still sign in as a service account you created. A tool that runs an executable has to run on the machine with the program, so it's installed there and reached through the same tunnel. Stop the tunnel connector, and nothing of ours can reach that network.
Where the model runs depends on who starts the work:
- Semi-autonomous: people work in a chat client the business already uses, such as Claude or ChatGPT, and it connects to our MCP server. The model runs with that chat client's provider, under the client's own account, and what a tool returns goes into that conversation.
- Fully autonomous: the agent runs in the client's AWS environment and calls models through Amazon Bedrock, so those model calls stay inside AWS.
Either way, the model sees what the tools return, so we keep each tool's output narrow.
Two checks, both on your side
We host the tools, but the two things that decide what they do live in systems you already manage.
Check 1: the client's identity provider decides who can use which tools. People sign in with single sign-on through the client's identity provider, such as Microsoft Entra ID, Okta, or Google Workspace, which issues OAuth 2.0 access tokens as JSON Web Tokens (JWTs). On every call, the MCP server validates the token (signature, issuer, audience, and expiry) and checks its groups against the tools those groups may call. If the groups don't allow a tool, it doesn't run. Removing someone from a group takes effect when their current token expires, about an hour by default in most identity providers.
Check 2: the service accounts you create decide what any tool can do. You, or the client's IT, create a service account in each system the tools need, scoped to what those tools do. Every tool call runs through one of them. The client's system enforces its permissions, not our code. Downgrade a service account from write to read, or disable it, and every tool call through it fails right away, no matter what our code tries.
How service account credentials are stored
We never ask for or hold admin accounts. We hold only the credentials for the service accounts you create, stored encrypted in that client's own AWS environment with a separate encryption key for each client. The tools use them to call that client's systems, and nothing else. They're never sent back out: the model never sees them, they never appear in logs, and the path you use to send them to us is write-only.
Credential rotation
You rotate service account credentials on your own schedule, in the system they belong to. Then you push the new credential to us through the same write-only path. We can't read it back.
We run an auth check for each client every day. If a service account stops working (it expired, was rotated but not sent to us, or had its permissions changed), we're alerted and contact you, usually before anyone runs into it.
Separate service accounts for people and agents
Semi-autonomous work. When a person triggers a tool call, it runs through one service account per system, shared by everyone using the agent. The person's token decides which tools they can call. The service account decides what those tools can do.
Fully autonomous agents. Each agent that runs on its own gets its own service account, scoped to its one job. You can shut off automated work without touching the tools people use. And an unattended agent that gets fed a malicious email can still do only its one narrow job.
If a client's AWS environment is compromised
Someone who got into a client's AWS environment would be stuck in that one environment. Each client's is a separate AWS account, so there's no path from it to any other client's. Inside it, they could do what that client's service accounts allow, and nothing more. There are no admin accounts to take, because we don't have any. Disable the service accounts, one click each in the system they belong to, and nothing on our side can reach the client's systems.
We sign in to manage each client environment through single sign-on with multi-factor authentication, using short-lived credentials. There are no long-lived access keys. Even with that access, our reach into a client's systems is only what that client's service accounts allow.
That's why we ask you to keep service accounts narrow: they're the real limit on what anyone can do with our tools, including us.
What else is in a client's environment: logs that record actions, not the data tools return, and, if the client has one, the RAG index of documents they chose to include, encrypted.
Every tool call is logged
Every tool call is logged: which tool, who triggered it, when, and whether it succeeded. Logs record the action, not the data. We don't store the records a tool returns, so the logs never become a second copy of the client's data. Logs are kept per client, encrypted with that client's key, and retained for 1 year. You can request an export or review them at any time.
Fixed tool logic and connector allowlists
Each custom tool is one named action with its query or API call written in our code. Custom tools take specific parameters, like a customer ID or a new status, never a free-form query. The model picks which tool to call and fills in the parameters. The model can't reach anything we didn't build or allow a tool for.
Where we use a vendor's own connector, we allow only the read tools the job needs, and it signs in with a read-only service account. The same checks apply: the token and group check on every call, the service account you create, and the log.
Read-only by default
Tools are read-only by default. Write access is granted per tool and per group, only where the job needs it, and the service account has to allow the write too.
Revoking access
Every lever is on your side:
- One person, some tools. Remove them from the group in the identity provider.
- One automated job. Disable that agent's service account.
- Everything in one system. Disable the service accounts for that system.
- Everything on the client's network. Stop the tunnel connector.
Guidance
These depend on how the client and your team run things. We recommend them and set them up where the client agrees, but code alone doesn't enforce them.
Human approval on steps that matter
Steps that change data or reach customers can pause for a person to approve them before they run. We recommend this for any step that would be hard to undo.
Review the logs
Logs help only if someone reads them. We keep audit notes on what the agents are doing, and we recommend the client or your team review tool-call logs on a regular schedule.
Keep groups and service accounts narrow
Give each job its own group, and give each service account only what its tools need. Review both when people change roles or the tools change.
Rotate on a schedule
Pick a rotation schedule for each service account and keep to it. Our daily check catches a credential that stops working, but the schedule is yours to set.
Why these controls
Deloitte AI Institute's report The agentification of the enterprise (2025) puts the risk plainly: "Agents introduce a new class of enterprise risks that scale nonlinearly across decision chains and interfaces." It adds that "connecting more data and systems with on-premises, cloud, and third-party technology creates new potential vulnerabilities." Here is how its recommendations map to how we build:
| Deloitte recommends | How we build it in |
|---|---|
| "Proactive, real-time monitoring for system anomalies, security threats, and unexpected behaviors" | Every tool call an agent makes is logged, and a daily auth check runs for each client |
| "Maintaining a human-in-the-loop with the authority to override decisions and perform dynamic audits of agent behavior" | Approval steps on actions that change data, and audit notes on agent activity |
| Limiting the new vulnerabilities that come from connecting systems | Scoped service accounts the MSP creates and can disable, identity provider groups checked on every call, and only the tools each job needs: fixed-logic tools for anything that writes, and vendor connectors limited to an allowlist of tools |
Questions MSPs ask
Where do the credentials live?
In that client's own isolated AWS environment, encrypted with a separate key for each client. They belong to the service accounts you create, and they're never sent back out. See how they're stored.
What happens if Hiveframe's hosting is ever compromised?
Each client runs in its own isolated AWS environment, so a compromise stays in that one environment and can't reach other clients. Even there, anyone could do only what your service accounts allow, and you can disable those accounts at any time. See the details.
How does rotation work?
You rotate on your own schedule and send the new credential through a write-only path. Our daily auth check flags anything that stops working.
Can the AI write data?
Only through tools that are allowed to write, only where the plan calls for it, and only if the service account allows it. Writes can also wait for a person to approve them.
What if a vendor API changes?
If it affects one of our custom tools, we fix the tool under the monthly care plan. If it affects a vendor's connector, the vendor updates its connector, and we monitor it and adjust our allowlist to match. Either way, failed tool calls show up in our monitoring, so we usually see it first.
What if we leave?
Give us 30 days' notice, and we export the client's configuration and logs. Then you disable the service accounts, and nothing of ours can reach the client's systems.
Something else? Bring your security team to a partner call, or email us at contact@hiveframesystems.com and we'll walk through it.
Book a free 20-minute partner call
Every build has a 30-day money-back guarantee.