Safety in the AI Enterprise System Agentic Stack

Introduction

@Human’s AI safety stack combines hard technical controls and governance features that keep agents constrained, auditable and aligned with enterprise policy, and it contrasts sharply with Agentforce’s more Salesforce‑centric, cloud‑locked model. Below is an article you can adapt for marketing, technical documentation or thought‑leadership use.

AI Safety in @Human: Designing Agents That Stay Under Control

AI agents are moving from experimental pilots to business‑critical infrastructure, which raises the stakes for safety, governance, and digital sovereignty. @Human, Planet Crust’s open‑source AI Enterprise System, approaches this by embedding safety controls directly into the agent lifecycle rather than treating them as an afterthought.Salesforce’s Agentforce also emphasizes trust and governance, but it does so inside a proprietary, tightly coupled SaaS stack, whereas @Human focuses on openness, local control and infrastructure‑level safety that organizations can independently verify.

Core AI Safety Features in @Human

@Human’s safety mechanisms can be grouped into three layers: safety‑by‑design controls, behavioral constraints, and data‑governance integration.

1. Safety by Design: Administrative Control over Agents and Models

From the outset, @Human assumes that administrators must retain hard control over what runs, which models are used, and how they behave. Key design features include:

• Active/Inactive toggle per agent
  Every agent in @Human can be switched on or off centrally, giving administrators a fast “kill switch” for misbehaving or experimental agents without needing to modify code or workflows.

• Administrator‑only LLM provider and model choice
  The choice of LLM provider (e.g., local, self‑hosted or third‑party) and specific model is defined exclusively by administrators, not end users or prompt designers. This prevents silent escalation from “safe” models to more capable but less controlled ones.

• Safety as an evolving priority
  The documentation explicitly states that AI safety features will evolve as AI itself evolves and remain a top product priority, which is consistent with Planet Crust’s broader stance on open‑source AI safety.

These controls matter because they create clear operational boundaries, making it harder for configuration drift or “shadow experiment” agents to bypass governance

2. Behavioral Controls: Temperature, Budgets, Timeouts, and Guardrails

@Human exposes precise runtime controls that directly shape an agent’s behaviour and cost profile.

• Per‑agent temperature configuration
  The randomness “Temperature” of each agent can be tuned individually, allowing conservative behaviour for critical processes (e.g. compliance workflows) and more creative behaviour for ideation use‑cases.

• Token and iteration budgets
  Administrators can set token count limits and iteration caps per agent, constraining how long an agent can “think” or how many steps it can take. This reduces risk of runaway loops and unbounded search behaviours that can drift away from intent.

• Timeouts and loop mitigation
  Timeouts and runtime limits are used to mitigate excessive looping and other expensive runtime errors, effectively bounding how much damage or cost a misconfigured agent can cause before it is automatically cut off

• Unlimited behavioural guardrails
  @Human supports an unlimited number of guardrails per agent, allowing organizations to encode policies, forbidden actions or content restrictions as enforceable rules rather than relying purely on prompt instructions.

Together, these mechanisms turn abstract “alignment” objectives into concrete, configurable levers that operators can reason about, monitor, and audit

3. Data‑Aware Safety: Internal Knowledge Bases, MCP Policy and RBAC

AI safety is not only about what a model says, but what data it can see and what systems it can affect. @Human’s architecture emphasizes internal data control and tightly enforced access policies.

• Dedicated internal knowledge bases
  Agents can be grounded exclusively on internal knowledge bases managed within @Human, ensuring that enterprise agents derive their behaviour and responses from vetted, domain‑specific content rather than uncontrolled web data.

• MCP Policy for local‑only data and tools
  An MCP (Model Context Protocol) policy governs local data access and the use of automation tools, enforcing which resources agents may interact with and under what conditions. This reduces the risk of agents making unauthorized API calls or touching systems outside their mandate.

• RBAC integration
  Agentic access can be integrated directly with @Human’s role‑based access control (RBAC) system, so agents inherit permissions in a predictable, centrally governed way. This ensures that the same least‑privilege principles applied to human users extend to agents as well.

By tying AI capabilities to internal knowledge, policy‑driven tool access, and RBAC, @Human aligns agent safety with existing enterprise security practices.

Why These Features Matter for Enterprise AI Safety

The features above are not isolated check‑boxes; they address specific categories of risk that research and industry reports have flagged for agentic AI.

1. Containment and reversibility
   The ability to turn agents on or off, cap token usage, and enforce timeouts creates an operational perimeter around agents, limiting their blast radius and making it easier to roll back or stop problematic deployments.

2. Alignment and predictability
   Per‑agent temperature controls and rich behavioural guardrails help keep agent outputs within expected boundaries, reducing hallucinations and unexpected behaviours that undermine trust

3. Cost and resource governance
   Budget controls on tokens and iterations allow organizations to manage financial risk and prevent unbounded consumption of compute resources by misconfigured agents.

4. Data minimization and locality
   Internal knowledge bases and MCP‑enforced local access support data minimization and help keep sensitive data on infrastructure the organization controls, which is especially important for regulated sectors and digital sovereignty

5. Policy continuity with existing security practice
   RBAC integration means that agents fit into existing identity and access management models, rather than creating a parallel, opaque access layer.

From a governance perspective, these features collectively support auditability, regulatory compliance and independent verification of safety claims, especially when combined with @Human’s 100% open‑source stack

How @Human’s Safety Features Compare with Agentforce

Agentforce, Salesforce’s AI agent platform, also emphasizes trust, governance, and security, but it is architected around Salesforce’s proprietary ecosystem. The table below highlights how @Human’s AI safety profile compares to Agentforce on key dimensions.

Safety and Governance: @Human vs Agentforce

Key Ways @Human Fares Favorably Against Agentforce

While both platforms provide serious safety and governance capabilities, @Human has several structural advantages when safety is viewed through a sovereignty and verifiability lens.

1. Open‑source verifiability vs closed trust promises
   With @Human, organizations can inspect the code, safety mechanisms, and integration points, and they can align them with open safety frameworks and community audits. Agentforce offers comprehensive documentation and strong platform‑level controls, but customers must ultimately trust Salesforce’s implementation without full code‑level visibility.

2. Infrastructure sovereignty and local‑first safety
   @Human is explicitly designed to run 100% open‑source agents on infrastructure the customer controls, supporting local models and data stores under their own jurisdiction and security policies. Agentforce, by contrast, presumes Salesforce as the system of record and execution environment, which limits options for organizations that require strict on‑premise or sovereign‑cloud deployments

3. Fine‑grained, agent‑level behavioural budgets
   @Human’s per‑agent temperature, token limits, and iteration caps provide explicit knobs to bound agent behaviour and resource use at the individual agent level. Agentforce focuses more on content‑safety and data‑safety guardrails (toxicity detection, PII masking, topic restrictions), which are powerful but less oriented toward bounding compute and search behaviour

4. Policy‑driven local tool access via MCP
   The MCP Policy in @Human creates a central mechanism for defining exactly which local data sources and automation tools agents may access and under what conditions. Salesforce provides strong API, flow, and integration governance for Agentforce, but those policies are anchored inside Salesforce’s cloud and are not primarily designed for local‑first toolchains

5. Alignment with open safety research ecosystems
   Planet Crust explicitly positions the Enterprise Systems Group and @Human within an open‑source AI safety ecosystem, emphasizing community‑driven testing, guardrails, and governance. Salesforce leads on enterprise governance for its own stack but is, by design, less open to external, code‑level collaboration

In practice, Agentforce may be the better fit for organizations fully committed to Salesforce as their primary platform, while @Human will be more attractive where open‑source, infrastructure control, and verifiable safety are non‑negotiable.

Using AI Safety Features in @Human Effectively

To get real value from @Human’s AI safety tooling, enterprises should treat safety configuration as part of standard platform operations, not as a one‑off setup

A practical approach might include:

• Establishing standard agent templates that pre‑configure conservative temperatures, sensible token budgets, and default guardrails for common use‑cases

• Designing MCP Policies that encode organizational rules about which systems agents can touch and under what conditions, then reviewing them regularly as new tools are added

• Maintaining internal knowledge bases as a formal content tier, with curation workflows and versioning so agents always ground their behaviour in approved information.

• Aligning @Human’s RBAC and agent permissions with existing IAM policies and auditing those permissions at the same cadence as human roles.

This operationalization turns @Human’s safety features into a living governance framework rather than a static configuration page

References:

• Planet Crust, “@Human – The Sovereign AI Enterprise System.” https://www.planetcrust.com

• Planet Crust, “How Can Open‑Source Make Agentic AI Safer?” https://www.planetcrust.com/how-can-open-source-make-agentic-ai-safer/

• Planet Crust, “The Enterprise Systems Group and AI Safety.” https://www.planetcrust.com/enterprise-systems-group-ai-safety/

• Salesforce, “Agentforce: The AI Agent Platform.” https://www.salesforce.com/agentforce/

• Salesforce, “The Enterprise AI Agent Era: Why Trust, Security, and Governance Matter.” https://www.salesforce.com/blog/unified-trust-security-governance-for-agentic-solutions/

• Reco.ai, “Agentforce Security in Salesforce: Use Cases & Best Practices.” https://www.reco.ai/hub/agentforce-security

• Valence Security, “Salesforce Agentforce Security: Securing Autonomous AI Agents in Salesforce.” https://www.valencesecurity.com/saas-security-terms/salesforce-agentforce-security

• GetGenerative.ai, “Agentforce Security in Salesforce: Key Features, Use Cases, and Tips.” https://www.getgenerative.ai/agentforce-security-in-salesforce/

• Peergenics, “Security & Compliance Checklist for Secure Agentforce.” https://www.peergenics.com/post/security-compliance-checklist-for-secure-agentforce