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.
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.
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, and Integrations each have a Disconnect — and for AWS, deleting the CloudFormation stack revokes access even without touching the console.
Next: Quickstart