Your AI, under the rules of business.
SECURITY AND AI GATEWAY
Permission starts at the source, can be restricted by the workspace, is scoped for each person or agent, and requires separate authority before an action can proceed.
Start now Explore AI Gateway From context to action Public principle 01 Origin Original permission
Data or document
02 Workspace Additional policy
It can only restrict
03 Consumer Usage scope
Person, engine or agent
04 Action Separate authorization
Proceed or block
Product principle · illustrative example Governance AI Gateway Agents Privacy Trust objectives
FOLLOWS DEVELOPMENT
How to read product states. Public principle
Public principle that SOCEO already assumes.
Under construction
Technical direction not yet proven complete.
Future objective
External marker not yet obtained.
ADD RESTRICTIONS FOR TEAMS AND INDIVIDUALS EXAMPLE DATA
illustrative example of policies per person.
Operational matrix: EXAMPLE DATA SCOPE MODEL CONNECTORS CONTEXT BUDGET / MONTH
Marina · Growth
JUST Claude
200K R$ 1.2 thousand +8%
Felipe · Management
ALL EXCEPT Claude
1M R$ 2.4 thousand +5%
Camila · Finance
ONLY OpenAI
64K R$ 800 -4%
Rafael · Operations
JUST Gemini
128K R$ 900 +3% Adoption only comes with governance
SOCEO is the governance layer that unlocks AI adoption in the company. Launch agents on day 0 with cost, connector and context controls per team and person.
Who each policy applies to Entire teams Individuals Specific exceptions What it limits for each agent Allowed models Context size Connector access Monthly budget
Example result
90% maximum context savings 100% agent adoption 6 months to full adoption
SECURITY IN DEVELOPMENT
Clear commitments. Next steps too.
Learn the principles that guide SOCEO and the controls that still need implementation, validation or external evidence.
Public principle Product principles Reliable source permission is preserved. The workspace only adds restrictions. Different roles receive different scopes. Viewing, using, executing and approving are separate authorizations. The block explains the layer without revealing the content. Under construction Controls to implement and validate Complete data isolation by context. Centralized corporate login and encryption with a proven scope. Continuous auditing, centralized security event monitoring and traceability coverage. Technical protections against prompt injection. External milestones for trust and compliance. Track progress on the roadmap
THREE BORDERS
The rule follows the data through to the decision.
Each border reduces possible access. No later layer erases a previous restriction.
01 ORIGIN
Origin defines the first limit.
When the source offers an available and reliable permission rule, SOCEO preserves that limit by bringing the data or document into the operational context.
Explore Permissions and trust Access is preserved when the source rule is available and reliable. 01 LAYER Source 02 APPLIED RULE Available permission 03 APPLIED RULE Data or document 04 RESULT Access preserved
02 CONTEXT
The context does not erase permission.
Workspace policy can restrict what a role can see or use. It never turns access denied at the source into permitted access.
View Operational context The most restrictive rule follows the derived context. 01 LAYER Source permission 02 APPLIED RULE Workspace policy 03 APPLIED RULE Role-based scope 04 RESULT Least access
03 ACTION
Action requires its own authority.
Being able to see information does not mean being able to use it in any flow, executing a change or approving a decision. Those authorisations shall remain separate.
Learn about Human approvals Viewing, using, executing and approving are separate decisions. 01 LAYER View 02 APPLIED RULE Use 03 APPLIED RULE Execute 04 RESULT Approve
POINTS OF GOVERNANCE
Six points where the limit needs to remain visible.
Walk the path to separate the principle already sustained from that which still requires construction or proof.
01 Provenance and identity 02 Permissions and scopes 03 Context and protected fields 04 People, engines and agents 05 Action and approval 06 Traceability and visible limits 01 / 06 Public principle Permission starts where the data originates.
When a source rule is available and reliable, it follows the data or document. The identity involved determines which scope can proceed.
DECLARED RULE The workspace cannot expand the original permission.
PERMISSIONS IN DEPTH
The most restrictive rule governs effective use.
See how source, workspace, and role determine the effective scope within the Conecta engine, without using workspace policy as a shortcut to expand access.
Explore Permissions and trust Permissions at each stage The least access prevails 01 Source Access allowed by the source 02 Workspace Additional restriction 03 Effective use Most restrictive intersection
RESULT Effective access never exceeds the limit of origin.
AGENTS IN PRACTICE
The same rule decides what the agent can do.
In a mission to investigate margin, read permission does not authorize spending. The scenario below shows how source, role, and approval change the action path.
ILLUSTRATIVE MISSION Investigate the margin drop and prepare an adjustment. 01 / ACTION Read financial report Remains within scope
The source grants read access to the role, and the workspace does not expand that access.
IN THE COURSE
Source and period follow the analysis.
02 / ACTION Open restricted contract Blocked
The source has not granted access. The mission declares the gap without showing the contents.
IN THE COURSE
The limit is visible to the team.
03 / ACTION Change budget Requests approval
The agent can prepare the proposal; executing the expenditure requires the authorized person.
IN THE COURSE
Human decision before action.
illustrative example of application of the principles. Complete technical coverage of isolation, auditing and protection against prompt injection continues to be built.
Explore Agent Governance
AI GATEWAY
The right AI, with the rules of your business.
A layer to view how each request could combine task, access policy, allowed context and model profile before producing a response.
Visual demonstration · no actual execution
This environment does not send requests, does not measure real use and does not receive credentials.
Simulate a route Explore the Model Center REQUEST DECISION LAYER 01 Task classify 02 Policy permit 03 Context minimize DEMONSTRATION ROUTE Balanced profile reason + alternative visible RESPONSE EXPECTED RECORD
REQUEST PATH
The route begins before the model.
Each step shows a different decision. The diagram describes the expected visual contract; it does not prove that these decisions are already applied by a backend.
01 Task
The request is classified by the expected type of work.
02 Policy
The applicable rules determine what can proceed.
03 Context
Only the authorized context enters the request scenario.
04 Model
A model profile is suggested for task and objective.
05 Response
Return keeps limits and alternatives visible.
06 Record
The signals that would need to be measured are made explicit.
TWO MODES OF ACCESS
Using your own key is a mode of the Gateway, rather than a separate product.
Switch the scenario to distinguish billing, credentials, eligible models, and responsibilities without turning an illustration into a technical promise.
How does the scenario access models? SOCEO credits My key
GATEWAY MODE
SOCEO credits Demonstration workflow BILLING Usage represented as workspace credits. CREDENTIAL No provider credential is shown to the user. ELIGIBLE MODELS Eligible profiles depend on the catalog and the rules that may be enabled. RESPONSIBILITIES Technical availability, limits and metering must be confirmed in the product before actual use.
AUTOMATIC ROUTING IN THE GATEWAY
Change the task. Change the target. Read the reason.
The simulation maintains classification, policy, model profile, justification and alternative on the same stage so that the decision can be challenged.
Visual demonstration · no actual execution
01 Task Prepare an executive summary Compare long documents Plan an action with a tool
Synthesize operational signals for a weekly review.
02 Route objective Cost savings Prioritizes a profile with lower relative cost for the task. Balance Seeks an intermediate combination of cost and capability. Capability Prioritizes a profile prepared for greater relative complexity. TASK POLICY PROFILE DEMONSTRATION MODEL Balanced profile Balance CLASSIFICATION Operational synthesis APPLIED POLICY Reading permitted context · no automatic action SCENARIO CONTEXT Indicators and notes authorized in the scenario
WHY THIS ROUTE? It combines synthesis, context understanding and room to explain differences.
Alternative Essential profile when the data are already consolidated.
EXPECTED IMPACT IN THE SCENARIO Seeks relative balance; this is not an estimate of actual usage.
Visual demonstration: the route changes locally on this page, without model call, actual cost calculation, telemetry or backend decision.
PRIVACY BY SURFACE
A different question for each data layer.
The provider, conversation, memory, files, telemetry, and credentials each have their own lifecycle and responsible owner. A blanket statement does not answer these separate questions.
01 Upload to provider
Which supplier, region and retention policy would apply?
LIMIT OF THIS DEMONSTRATION Retention and use by the supplier must be declared by contract; nothing here assumes zero retention. 02 Conversation history
The conversation is available after the session, for how long and for whom?
LIMIT OF THIS DEMONSTRATION Product history is a separate surface from the treatment made by the supplier. 03 Reusable memory
What could come back in another conversation and how would it be removed?
LIMIT OF THIS DEMONSTRATION Memory requires its own policy; this page does not state that it exists or is isolated. 04 Archives and excerpts
Which files and parts would be sent to answer the task?
LIMIT OF THIS DEMONSTRATION Permission, minimization and disposal need to be proven in real implementation. 05 Logs and telemetry
Which metadata, errors and measurements would be recorded?
LIMIT OF THIS DEMONSTRATION Observability should not be confused with conversation content or with supplier retention. 06 Own credentials
Who registers, revokes and answers for the key used?
LIMIT OF THIS DEMONSTRATION The demonstration only shows a mask and does not receive, validate, store or transmit keys.
OBSERVABILITY AND CONTROLS
What a real operation would need to make visible.
The fields below are an administrative framework. Dashes in place of numbers make clear that this page has no production telemetry.
Visual demonstration · no actual execution
WORKSPACE VISION Without Real Data Volume No Real Data
Requests by workspace and period.
Cost No actual data
Cost or credit measured per route.
Latency No real data
Time observed by profile and task.
Errors No actual data
Failures and refusals grouped by cause.
Tools No real data
Calls proposed, approved and completed.
ADMINISTRATIVE CONTROLS visual contract 01 Eligible models
Set which profiles can participate in each route.
02 Limits of use
Represent ceilings and conditions by workspace or group.
03 Human approval
Interrupt sensitive scenarios before any action.
04 Route alternatives
State what should happen when the preferred route cannot proceed.
AVAILABILITY
Separate what is demonstrated from what is operational.
Each block declares the scope of this composition so that a convincing interface is not confused with proven backend, billing, security or telemetry.
Visual demonstration · no actual execution
Router of this page Visual demonstration
Local interaction without calling models, calculation or persistence.
Credits SOCEO Availability to confirm
The flow needs to be validated in the product before it becomes operational promise.
My key Technical activation to confirm
The interface does not register, validate or use a real key.
Automatic routing Demonstrated behavior
The criteria and profiles displayed are editorial, without real telemetry.
MODELS AND GOVERNANCE
Compare the profiles before setting the route.
The Model Center presents demonstrative profiles that can inform a future Gateway policy.
Open the Model Center Talk to the team
FUTURE OBJECTIVES
Directions for trust, without claiming achievement.
These milestones have not yet been achieved. They describe future directions, rather than certifications, reports, current compliance, or ongoing audits. Scope, order, and applicability may change.
42001 ISO/IEC 42001:2023 Future objective — not yet achieved NATURE Artificial intelligence management system DIRECTION / SCOPE Direction for structuring responsibilities and management of AI use. HIPAA* HIPAA, where applicable Future objective — not yet achieved NATURE Requirements applicable to health information DIRECTION / SCOPE Applicability will depend on the product, processed data and obligations involved. TX–L2 TX-RAMP Level 2, where applicable Future objective — not yet achieved NATURE Government program applicable to cloud services DIRECTION / SCOPE Scope and need will depend on activity compatible with the program. SOC 2 SOC 2® Type 2 Future objective — not yet achieved NATURE Independent examination and report DIRECTION / SCOPE Treated as an independent examination with a report, rather than a generic seal or certification. 27001 ISO/IEC 27001:2022 Future objective — not yet achieved NATURE Information security management system DIRECTION / SCOPE Direction for organizing controls and continuous improvement of information security. GDPR* GDPR, where applicable Future objective — not yet achieved NATURE Applicable data protection requirements DIRECTION / SCOPE Applicability will depend on the operations, people and data involved.
FREQUENT QUESTIONS
Your security questions. Does SOCEO already have certifications? Can the workspace expand a source permission? Does every AI action happen automatically? How does SOCEO communicate a block? Where can the evolution of controls be tracked?
NEXT STEP
See governance in the real path of information.
Talk to SOCEO about sources, roles, limits and approvals in the context of your business.
Start now View roadmap