Trust and Security: The Architecture Behind A.S.T.R.A.

It means four separate, checkable things, not one abstract promise. Where does the data live while the agent works on it. Who is the agent acting as when it writes. Who has to agree before a consequential write happens. And what gets recorded so a wrong action can be found and undone. A vendor that only answers one of these, usually the first with a security page, has not actually addressed what happens once an agent is live and drafting changes to a real customer record. Mindlyft is built so all four have a direct, verifiable answer rather than a policy statement about intentions.

Your CRM and tools stay the system of record: A.S.T.R.A. writes its results back into the Salesforce, HubSpot, Jira, Gmail, and Slack accounts you already own. To do that work, A.S.T.R.A. keeps a working set in its own backend: the call transcripts it extracts from, the actions it drafts for review, the audit trail, and the connector credentials you grant it. That working set is separated per customer and enforced on every request, not by convention, and every stored secret is encrypted with AES-256-GCM bound to the customer and to the field it belongs to, so a ciphertext copied anywhere else does not decrypt. Nothing in that working set replaces your CRM as the record of what happened.

Scoped credentials and server-side checks, not trust in the model. Each connector A.S.T.R.A. writes through is connected by an admin of your org through the provider's own OAuth consent, so its reach is exactly what that consent grants in your Salesforce, HubSpot, Jira, Gmail, or Slack, and you can narrow or revoke it there at any time. Only an org admin can connect or swap a connector; a regular user cannot point your CRM at a different account. Every action carries the identity of the person who approved it, and roles are checked on the server for every org-wide setting, so a member cannot change an admin control by calling the backend directly.

By default, a named person has to say yes. A.S.T.R.A. gates actions by consequence: a reversible, internal write runs on its own because it is cheap to undo, while anything that reaches a customer or changes a system of record, a stage change, an amount, a sent email, is drafted and held until a person approves, edits, or rejects it. A drafted action sitting unreviewed does not expire into an execution. An org admin can choose to let a specific action type run automatically, and only when it is rated low risk, the extraction confidence is at least 0.95, and that type has earned a trust score above the admin's threshold; it never applies to accounts the admin marks white-glove, and every automatic action is logged the same way. The gate is enforced in the execution path on the server, which only runs actions it stored itself, not in a prompt asking the model to behave.

It is written into a tamper-evident audit trail, hashed with SHA-256 so the record of what happened cannot be quietly altered after the fact. Each entry captures what the agent did, what it acted on, who approved it if approval was required, and what is needed to reverse it. That last part is not an afterthought: every executed write carries enough context that undoing a mistake is a single action rather than a data-recovery project. The trail exists specifically so trusting A.S.T.R.A. does not depend on trusting that it behaved; it depends on being able to check.

It can be tested directly, because each control lives in a system outside Mindlyft's own claims about itself. Scope is verifiable in the target system: look at what an agent's credential can actually touch in Salesforce or HubSpot and compare it to what the job needs. The gate is verifiable by attempting a consequential action and confirming it is held rather than executed. The trail is verifiable by tracing a sample of writes in the CRM's own audit log back to a proposal and an approver. And the kill switch is verifiable by pausing execution for your org and confirming nothing runs until it is resumed, or by disconnecting a connector and confirming its credential is gone. None of these checks require taking Mindlyft's word for it, which is the point: the controls are enforced in systems the customer already owns and can inspect.

Reads are broad, writes are narrow, and that asymmetry is deliberate rather than an oversight. A.S.T.R.A. can read widely across a connected tool, pull a record, summarize a call, check a field, because a wide read path is safe: nothing changes as a result of a read. The write path is the one that is scoped tightly, limited to the specific fields and objects a given agent is permitted to change. Treating the two differently is what keeps the system useful, an agent that could not read context broadly would draft worse actions, while still keeping the one path that can actually damage a record narrow and attributable.

Yes, by default rather than by a new policy someone has to remember to write. The classification a new action type gets is the cautious one until it earns otherwise: if it is hard to reverse or visible to a customer, it is treated as consequential and held for a person, the same as every other action in that category. A new connector does not get a blanket allow because it is unfamiliar, and it does not need a bespoke security review before day one, because the scope, gate, and trail apply to it the moment it is registered under an agent's identity. Controls that depend on someone remembering to apply them to the next integration eventually get missed; controls that are the default for anything new do not have that failure mode.

Each customer's data is isolated on the server for every request: a signed-in user of one customer cannot read or change another customer's records, and the backend refuses any request that does not carry a valid identity. Every stored secret, connector credentials, webhook secrets and signing keys, is encrypted with AES-256-GCM and bound to the customer and the field it belongs to. Sessions are re-checked against the user directory every minute, so a removed or demoted user loses access within a minute, and no session outlives twelve hours. Sign-in is rate limited per account and per network address. Lead phone numbers are pseudonymised before they reach the audit trail. Mindlyft ran two rounds of security review on 2026-10-03 and 2026-10-04: every issue found was reproduced against the old code, fixed, and covered by a test that fails if the issue returns. Researchers can report issues through the contact in mindlyft.in/.well-known/security.txt.

A certificate attests that an organization's processes were reviewed at a point in time. It says something about how a company runs, not about what a specific agent can do to a specific record on a specific day. The four controls above answer the second question directly: an agent's reach is limited by the org-scoped credential your admin granted right now, not by a policy someone wrote; a consequential write is held for a human right now, not eventually audited after the fact; and a mistake is reversible right now, with the context needed to fix it attached to the entry. Mindlyft is upfront that this page describes architecture, not a list of certifications, because the architecture is what actually determines what an agent can do to your systems on any given day.