Trust and Security: The Architecture Behind ASTRA

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.

Inside your own accounts. Mindlyft runs inside the CRM, automation tools, and repos a team already uses, rather than a separate platform that imports your data and holds it. There is no Mindlyft database that becomes the system of record instead of your Salesforce or HubSpot, and no login to a hosted app that stops working the moment a subscription pauses. This is also why cancelling never strands a team: because the work was never anything other than configuration and writes inside accounts the customer already owns and controls, nothing has to be exported or migrated out when the engagement ends.

A scoped identity, issued per agent rather than shared. ASTRA does not log in as you and does not use one master key across every workflow it runs. Each agent that writes to Salesforce, HubSpot, Jira, Gmail, or Slack holds its own named identity, permissioned to only the objects and fields that specific job needs. That is what makes a write attributable to a specific agent rather than to "the integration" in general, and what lets one workflow be turned off without touching any other, because disabling an identity revokes exactly the access that identity held and nothing else.

A named person has to say yes. ASTRA gates actions by consequence: a reversible, internal write, logging a call, filling a field that does not touch pipeline math, drafting a follow-up into a holding queue, runs on its own because it is cheap to undo if something is off. Anything that reaches a customer or changes a system of record, a stage change, an amount, a sent email, a merged record, is drafted and held until a person approves, edits, or rejects it. A drafted action sitting unreviewed does not expire into an execution; nothing happens to the CRM or a customer's inbox because a draft went unanswered. The gate is enforced in the execution path 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 ASTRA 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 workflow 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 disabling an agent and confirming its credential stops working everywhere, immediately. 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. ASTRA 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 workflow 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.

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 its own scoped credential 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.