The part that is the same in every product
Handing an AI agent a spend API, a deploy button or a database is only reasonable if the boundaries are real. These are the boundaries — enforced in ordinary code, on every path, every time, whichever of the five platforms you are using.
Agents that cannot go rogue
Agents never receive root, hypervisor or cloud credentials. They request typed tools, and every request is authorised on the server against the risk of the action — not against a promise made in a prompt.
| Risk | Examples | What happens |
|---|---|---|
| Low | Read metrics, inspect logs, generate code, run tests | Runs automatically |
| Medium | Restart a pod, deploy to preview, renew a certificate | Policy-controlled, tenant configurable |
| High | Production deploy, resize a database, change a firewall rule | Explicit approval |
| Critical | Delete data or a server, restore over production, broad IAM change | Approval + step-up authentication |
Spend caps are code, not prompts
Daily and monthly limits, a ceiling on how much any single action can change a budget, and a minimum conversion sample before anything scales. None of it is delegated to a model.
guardrails.evaluate() runs before the proposal and again at execution
A model cannot invent a number
Every model result is validated against a strict schema before use. A split that does not total 100, an unknown platform, an over-long headline — rejected, and the deterministic planner runs instead.
provider · model · prompt version · tokens recorded per call
Autonomy is bounded
Even on autopilot, low-confidence proposals route to a person, publishing a plan always needs approval, and a per-brand daily action limit stops a runaway agent.
RECOMMEND_ONLY · APPROVAL_REQUIRED · AUTOPILOT
Your models, our GPUs, one gateway
Webyne-hosted models run on a pool of 32 A100 40GB GPUs — 1.28 TB of HBM — cost-controlled and private to your tenant. Premium providers route through the same gateway when you choose them, and provider keys never leave the server.
| Pool | GPUs | Workload |
|---|---|---|
| Inference A | 8 | General & coding replicas |
| Inference B | 8 | General & coding replicas |
| Agent / RAG | 8 | Agents, embeddings, rerank |
| Reserved | 8 | Fine-tuning, dedicated, failover |
Aliases, not versions
Ask for webyne-max and the router handles model versions, health and failover. You do not pin a version string that goes stale, and you do not rewrite code when a model is replaced.
Tenant boundaries the database enforces
Isolation that depends on every query remembering a filter is isolation you cannot audit. Ours is enforced one layer down.
- Row-level security is forced on every tenant table; a query without a tenant context returns nothing.
- Secrets live in a secrets manager and are referenced at deploy time — never in prompts or repositories.
- Build and agent sandboxes are ephemeral, non-privileged and egress-controlled.
- Content pulled from files or the web is data. It can never grant a tool permission.
Access that does not leak sideways
In FileNest the same principle applies to people rather than tenants: access granted on a folder is inherited by everything inside it, at any depth, and never travels sideways to a sibling folder or upwards to a parent. Sharing a subfolder does not expose the folder containing it.
Every change accounted for
Each mutation carries an idempotency key, its previous state and a hash-chained audit entry. Any retroactive edit breaks the chain and is detectable. Every model call, tool call and infrastructure change lands in an immutable log with a trace id.
Evidence, then action
Remediation starts as a recommendation with the metric window that breached, the log lines inside it, and the change that preceded it. You promote actions to automatic once you trust them.
Survives deletion
Every action against a file is recorded — who did it, when, and from where — and the record survives the file being deleted. Retention windows are configurable to match your own policy.
Restores are tested
Every database backup is restore-tested into a throwaway instance before it is marked verified. An untested backup is not a backup.
Your data stays in the country
Storage, backups and processing on infrastructure located in India — billed in rupees, with GST invoices and support in your timezone.
Stored and processed in India
- Primary storage in India
- Backups held in-country
- No cross-border replication by default
Auditable by design
- Full audit trail per file
- Configurable retention
- Exportable access logs
Priced in rupees
- INR billing
- GST-compliant invoices
- No forex markup
Support in your hours
- 9am–9pm IST, Mon–Fri
- English and Hindi
- Onboarding help included
Read the rules, then try it.
Start with a free assessment, or open the platform that matches the problem you have today.