Skip to main content

Platform security

Three questions decide whether an agent platform is safe to put real work through: can another customer reach my data, where can a tool send it, and what protects the credentials that open the door. This page answers each one with what is guaranteed and what is not, so you can evaluate the answer rather than take it.

Credential storage and identity have their own articles - see Credential handling for how integration secrets are encrypted, scoped, and removed.

Workspace isolation​

Every tenant-owned record carries the organization that owns it, and that ownership is part of how the record is read, not a label attached afterwards.

  • Reads are scoped, not filtered late. Every read is constrained to your organization before it happens, so a record belonging to another workspace is never loaded and then hidden - it is never loaded.
  • Ownership cannot cross a workspace. A record can only reference records of its own organization, so a relationship can never span two workspaces, whatever asked for it.
  • A second floor sits under the first. Beneath that scoping, a request running inside an organization that somehow omitted its scope returns nothing rather than another tenant's records, and a write aimed at another organization is refused outright. This is defense in depth, adopted path by path rather than replacing the scoping above.
  • New kinds of record are held to it. A new tenant-owned record type cannot ship without the same protection.

When Yekar.AI staff need access​

Support access is never ambient, and it is yours to refuse: while Allow support sessions is off in Settings → Support sessions, no support session can start in your workspace, and turning it off ends any that is open. Turn on Require approval and every session must first be approved by one of your Owners or Admins, who are emailed each request; nothing is usable until one of them approves, and the session's clocks start at the approval. When it is on, a staff member acting inside your workspace does so under an explicit, recorded grant with a read or write mode, an idle timeout, an absolute expiry, and a kill switch that ends it immediately. Routes that write credentials are blocked for the duration, so a support session can never store a secret in your name. The session's audit rows carry the grant that produced them, which is what keeps the record readable long after the session is over. Every page the session opened is recorded too, by address and never by content, and you can read that list under Settings → Support sessions. The person behind a session is re-checked on every request: if their access is removed or lowered, the session ends there.

See Audit before effect for the trail every action leaves, and Permissions for the roles that bound your own team.

What a tool can reach​

A compromised tool - a prompt-injected argument, a hostile upstream response, a bug in a connector - is only as dangerous as the network it can reach. Yekar.AI routes every outbound request from a shipped integration through a single door and enforces the tool's own declaration there.

  • Declaring nothing means reaching nothing. A tool that does not declare where it may send traffic gets no outbound capability at all. Omission is refusal, not permission.
  • Hosts are matched exactly or by verified suffix. A declared api.example.com admits itself and its subdomains, and never a lookalike domain that merely ends in the same letters.
  • Addresses are checked before the request leaves. The resolved address is tested against private and reserved ranges first, so a public hostname pointed at an internal or cloud-metadata address is refused rather than fetched.
  • Redirects never inherit clearance. A redirect is either an error or surfaced to the caller; the next request re-clears every check from the start, so a hop can never carry the first request's approval somewhere it would not have been allowed.
  • Exceptions are enumerated, not ambient. Where a vendor's own client library cannot use the shared door, that integration applies the same address guard itself, and the list of such exceptions is fixed and reviewed rather than open.

Every attempt is recorded by destination - the hostname and the address actually dialed, never the path or query - so the record of where a tool reached does not itself become a place secrets accumulate.

Some integrations go further and never see their own secret: the integration works with a placeholder, and the real value is substituted after the destination checks have already passed. An integration that tried to send that secret somewhere else would be sending the placeholder.

Sign-in and API credentials​

  • Passwords are hashed with Argon2id, the memory-hard function, and are never stored or logged in a recoverable form.
  • A password found in a known data breach is refused - at signup, when an invitation is accepted, at a reset and at a change. Only the first five characters of a one-way fingerprint of the password are sent for that check, so the password itself never leaves Yekar.AI; if the check cannot be made, the password is accepted rather than blocking the person.
  • Two-factor sign-in is available to every person and enforceable by every organization. A time-based authenticator code (the open standard every authenticator app implements), or a six-digit code emailed to the account's own address where the deployment can send mail, is asked for after the password or Google step and before a password reset completes; the key is stored encrypted, recovery codes and emailed codes are stored only as hashes (an emailed code lives ten minutes and works once), wrong codes are rate limited and locked out like wrong passwords, and no code, key or address ever reaches a log or an audit row. A person may choose to remember a browser for thirty days, and that browser then skips the second step for that long while the password or Google step still runs every time - so for them the second factor is asked once per thirty days per browser, not at every sign-in; the choice is listed with a Forget action and is withdrawn by a password change or reset, a change of sign-in address and Sign out of all devices. Yekar.AI's own staff take the same second step when they sign in to Yekar.AI's internal tools. See Two-factor sign-in.
  • Sessions are held on the server and can be ended one at a time. Each sign-in is a record Yekar.AI keeps, and a browser stays signed in only while that record exists: a person ends any one of their sessions from Settings → Account → Where you're signed in, a password change or reset ends every other one, and a session unused for three days signs itself out - an organization can shorten that to as little as 15 minutes under Settings → Privacy. Ten failed sign-ins for one address within fifteen minutes lock it for the rest of the window. Yekar.AI's own staff sessions on its internal tools are held the same way, end after 30 minutes unused and 12 hours at most, and can be ended one at a time.
  • An organization can require its own single sign-on. With Require single sign-on on, a password or Google sign-in still proves who someone is but does not open that workspace; turning the requirement on ends every session in it that did not come through the identity provider. See Single sign-on.
  • API keys are shown once, expire, and open only what they were made for. A key is random 32-byte material; only its hash is stored, alongside a short hint so you can tell keys apart in a list. Yekar.AI cannot show you an existing key again, because Yekar.AI does not have it. Every new key expires - after 90 days unless you choose otherwise, and at most a year - and carries the scopes its owner ticked at creation, so a key made to fire triggers cannot build agents; a request outside its scopes, or with an expired key, is answered as if the route did not exist. Rotate replaces the secret and keeps the name and scopes, so a system can be moved to a fresh key before the old one lapses. See API keys.

For machine access, see Authentication.

Transport and browser protections​

  • Session cookies are always Secure, HttpOnly and SameSite. They are never issued over an unencrypted connection in any deployed environment; the only exception is an explicit local-development setting that refuses to start anywhere but on a developer's own machine.
  • Weak or example secrets refuse to start the service. The keys that seal sessions and encrypt stored credentials are checked when the service starts; a missing, short, predictable or example value stops it from starting rather than running on a secret someone else could know.
  • Every response carries browser security headers. Strict Transport Security (HTTPS only, for a year, on every subdomain), a refusal to be displayed inside another site's frame, no content-type guessing, a restrictive referrer policy and a policy denying device features such as camera and microphone. The API sends a Content Security Policy that allows nothing to load from its responses.
  • Each web app declares what it may load, and the browser holds it to that. Every Yekar.AI web surface - the product app, the admin and developer consoles, the marketing site and this documentation - sends an enforced Content Security Policy listing the origins it may talk to, and none of them allows an inline script it did not ship: where a page needs inline scripts, the policy names each one by its hash. Violations are reported to Yekar.AI, recorded as the kind of resource and the site involved, never the page address or its contents. In the product app the policy limits images to Yekar.AI's own API and file storage, so an image link written into an agent's reply - or into a knowledge article - cannot fetch from an arbitrary server. Such an image does not display; images you upload to Yekar.AI do.

What this page does not claim​

Yekar.AI contains a credential up to the moment it is used, and using it is the point of the call - once a request reaches a vendor, their systems hold it under their terms.

Secret scrubbing across execution output is defense in depth rather than a guarantee: exact values and their common encodings are removed from the paths Yekar.AI controls, but a provider that transforms or splits a secret into an unrecognized form can defeat any scanner. Keep credentials out of agent-authored content and knowledge articles.

A Content Security Policy is a browser control: it protects people using a browser that enforces it, and it limits what a page can load or run, not what a compromised server could send. Database connections run on the hosting provider's private network; encrypting them in transit is supported but is a deployment setting rather than the default.

Yekar.AI does not currently claim any third-party security certification. Where a specific control matters to your procurement process, ask - a straight answer about what exists is more useful than a badge.

Where to go next​