Know what Mica can see and change before you connect.
Mica connects to your cloud with credentials you create. For incident investigation it reads by default. For deployments its connections can make changes, so it asks before it acts.
Mica follows these rules in Microtica Platform and Deep Investigation alike.
Mica asks before it acts
When Mica proposes a change, such as a deployment, a rollback or a scaling update, it waits for a person to approve or decline it.
Credentials you control
Access comes from a role, service account or token you create. Delete it on your side and access ends.
Your cloud account
Your applications and infrastructure run in your own AWS account or cluster. To keep investigation evidence there too, host Mica's incident investigation in your account.
A record you can check
Mica lists every step it takes, and CloudTrail logs its AWS calls. Deployment history and logs stay with each environment.
By product
What each connection grants.
The products ask for different access because they do different jobs.
Connections can make changes
Microtica Platform
Sets up infrastructure and deploys applications, so its connections need write access.
AWS: a CloudFormation stack creates a role that Microtica assumes through AWS STS. It can provision and manage resources within that role's permissions.
Kubernetes: the published setup manifest grants broad cluster administration permissions. Review its RBAC with your team.
Launching or removing an app, releases, deployments, builds and scaling proposals from Mica use approval cards. You see the target before you approve or decline.
Git push pipelines and saving schedules you configure run on their own triggers. Mica approval cards do not gate them.
Do not treat the Platform connection as read-only. Review the connection permissions before granting access.
Where Mica investigates incidents across your accounts and clusters. These connections can read but not change your infrastructure.
AWS: a CloudFormation stack you launch creates an IAM role with the AWS-managed ReadOnlyAccess policy. Only Microtica's AWS account can assume it, with a per-connection external ID and one-hour sessions.
No access keys leave your AWS account. Each call is attributable in your CloudTrail.
Kubernetes: a service account limited to get, list and watch. That includes reading Secrets, so narrow the manifest before applying it if needed.
A run that needs approval pauses until someone answers. Moving an investigation into another connected account also needs a person to approve it.
You can stop a run at any time. Connection secrets are encrypted at rest with AES-256-GCM.
You can host Mica's incident investigation in your own cloud account, so evidence, credentials and cases stay in your environment.
The ceiling is the credential you grant. Give Mica broader credentials and it can act with them, so review each grant.
Platform's cloud and cluster connections support deployment and management. Their permissions also apply when Mica investigates a failure. Review access before connecting.
Integration
How access works
How to revoke it
AWS
A CloudFormation stack creates the role Microtica uses. Microtica assumes that role through AWS STS with temporary credentials. It can provision and manage resources within that role's permissions.
Delete the connection's CloudFormation stack in AWS.
Connect an API endpoint and service account token. The published setup manifest grants broad cluster administration permissions. Review its RBAC and namespace requirements with your team.
Revoke the service account's permissions and token in your cluster, then remove the connection.
A CloudFormation stack creates the role Microtica uses. Microtica assumes that role through AWS STS with temporary credentials. It can provision and manage resources within that role's permissions.
How to revoke it
Delete the connection's CloudFormation stack in AWS.
Connect an API endpoint and service account token. The published setup manifest grants broad cluster administration permissions. Review its RBAC and namespace requirements with your team.
How to revoke it
Revoke the service account's permissions and token in your cluster, then remove the connection.
Need an evaluation with narrower permissions? Discuss the workload and required actions with the team before connecting it. For read-only incident investigation, see the security guide.
Approvals in Microtica Platform
Read the proposal, then make the decision.
App launches and removals, releases, deployments, builds and scaling proposals have review cards. Check the target environment and affected resources or versions before approving one of Mica's actions.
Demo project
/Mica
/Production release
Sample data
Sample production approval card from Mica: deploy catalog-service v1.5.0 and order-worker v2.1.0 to Production, with Deploy to production and Decline buttons. Beside it, a Git push pipeline trigger and a saving schedule are shown as automation that runs on its own triggers, outside the approval card.
Both services passed in Staging. Here is the production release for your review.
Needs your approval
Deploy 2 services to ProductionProduction
Running now → New version
catalog-serviceservicev1.4.2 → v1.5.0
order-workerservicev2.0.1 → v2.1.0
order-worker changes its memory limit in this version.
Deploy to productionDeclineEdit in deploy dialog
Runs on its own trigger, without a chat approval
catalog-service pipeline
Trigger
Push to main
Deploys to
Staging
Deploy on push
On
Development schedule
Runs
Mon to Fri, 08:00 to 18:00
Resources
5 of 6 types
State
Stopped
Review the target and change
Deployment proposals identify the environment and resources or versions involved. Scaling proposals show the requested configuration. Approve or decline in the conversation.
Review automation separately
Configured Git push pipelines and saving schedules have their own triggers. Mica approval cards do not replace those settings.
Your code stays in Git and your resources stay in your account. Continuing to operate them also depends on pipelines, secrets, configuration, and infrastructure state.
What does disconnecting do?
In Platform, disconnecting stops Microtica management, including deployments and schedules using that connection. It does not delete resources in the account. In Deep Investigation, delete the CloudFormation stack or the Kubernetes manifest objects. In both, revoke provider-side access as well.
Can we keep running after we leave?
For Platform, your team needs a replacement operating process. Review infrastructure code, Terraform state access, secrets, pipelines, and rollback procedures with us before offboarding.
What about AI data handling?
For either product, request the applicable AI provider, retention, training, and data residency terms during evaluation. The privacy policy describes the published privacy terms.
Bring your account structure and production change process to a technical demo. Ask to walk through connection permissions, an approval, and offboarding steps for your architecture.
Bring your team's requirements.
Walk through either product against your architecture and controls.