microtica agents
Start free
Docs menu

Security & access

Microtica Agents works with whatever access you grant it — no more, and no less. This page states exactly what each grant is, how it’s stored, and where the human approvals sit. The rule to keep in mind: the ceiling on what the Investigator can do is the credential you hand it, and you set that credential.

What you grant, per integration

AWS — a CloudFormation role you deploy. You launch a CloudFormation stack in your own AWS account; the template is open for review before you create anything (Review the exact IAM policy on the connect screen). The stack creates an IAM role with the AWS-managed ReadOnlyAccess policy. The role trusts only Microtica’s AWS account, gated by a per-connection external ID, and sessions are capped at one hour. No access key ever leaves your account, and every call the Investigator makes is attributable in your CloudTrail. To revoke, delete the stack — access is gone.

Kubernetes — credentials you provide. You apply a plain YAML manifest yourself (the connect screen links the exact file): a service account bound to a cluster role with get, list, watch on all resources — no verbs that can change the cluster. Be aware that read access to all resources includes reading Kubernetes Secrets; review the manifest and narrow it before applying if that’s not what you want. You paste the endpoint and token; to revoke, kubectl delete the manifest’s objects or press Disconnect in settings.

Git — an authorization you approve. GitHub connects through a GitHub App you install; GitHub shows the exact permission set on the install screen, and no long-lived token is stored — short-lived installation tokens are minted per request. GitLab and Bitbucket connect through OAuth; the GitLab grant requests the api and write_repository scopes, which include write access. The Investigator’s repository tools today only read — files, directories, commits, diffs, branches, pull requests, code search — but you should treat the grant, not the current toolset, as what you’ve given.

Cloudflare — an API token you create. You paste a token; Microtica verifies it with Cloudflare and stores it encrypted. Access follows the token’s permissions exactly: if your token can edit DNS or Workers, the Investigator’s Cloudflare tools can too. Scope the token to what you want reachable.

MCP servers — a URL and optional bearer token. Microtica connects to the server and lists its tools before saving, so a bad URL or token fails at connect time. Connecting a server doesn’t make it trusted, though: its operator defines the tools it exposes and receives whatever data your calls send it, and those tools can read or change whatever the server itself has access to. Review the operator and its tool list before connecting, and scope the bearer token to the minimum the server needs. The token, when there is one, is encrypted at rest and sent only to that server.

How credentials are stored

Connection secrets — the Kubernetes token, the Cloudflare token, OAuth tokens — are encrypted at rest with AES-256-GCM, in a per-connection envelope. AWS is the exception in the good direction: nothing is stored at all, because access works by assuming the role in your account.

What you grant outward: MCP API keys

An MCP API key runs in the other direction — it lets an external MCP client start and follow investigations without opening the console. Only the key’s SHA-256 hash is stored, so the raw key is shown exactly once, at creation. A key’s AWS and/or Kubernetes context is limited to the specific connections you bound it to, but the investigation it starts still runs with the project’s other connected integrations — Slack, Cloudflare, and any custom MCP servers — regardless of that binding, so treat a key as scoped to AWS/Kubernetes access, not to the project’s full integration surface. Revoking the key takes effect immediately.

Be clear about the ceiling

The AWS template and the Kubernetes manifest are read-only by construction. But the product does not cap the Investigator below what a credential allows — it is built to operate with what you connect. Grant broader credentials and it can act with them, including creating and modifying infrastructure. That’s a deliberate design, and it means every grant deserves the two minutes of review the connect screens give you.

What stays under your control

  • Widening scope is yours to approve. An alert-triggered investigation is bound to one AWS account. If the trail points to another account, the Investigator reports it and stops at the boundary; only a human pressing Widen to <account> & continue — and only for an account already connected to the project — lets the case cross. An inbound alert can never escalate its own access.
  • Sensitive actions pause for you. A run that needs approval pauses and waits — in Slack: “Paused: a command needs human approval — open the case to review.”
  • You can stop a run at any time — while a run is active, the send button in the case’s composer becomes a Stop control.
  • You can disconnect anything from project settings — Cloud, Git, Integrations, and MCP → External Servers each have a Disconnect, and MCP → Client Access has a Revoke — for AWS, deleting the CloudFormation stack also revokes access without touching the console.

Next: Quickstart