You can encrypt them, but then no one can easily read them, including you.
First make a backup copy of the procedures and store them somewhere for your
use only (source code control is perfect for this), then use the WITH
ENCRYPTION key words to encrypt the procedures.  For example:

CREATE PROCEDURE uspTest
AS
SELECT *
FROM Authors
GO

sp_helptext uspTest
GO

ALTER PROCEDURE uspTest
WITH ENCRYPTION
AS
SELECT *
FROM Authors
GO

sp_helptext uspTest
GO

The first execution of sp_helptext will show what's been stored in the
Syscomments system table, but the second execution of sp_helptext will show
this message:  "The object's comments have been encrypted."  Everyone who has
permissions to run the SP will be able to, but no one will be able to read
the source after the encryption unless he uses a hacker's tool.

If encryption is news to you, realize that it's probably not news to the
company's DBA and programmer.  If they're experienced, they already know how
to decrypt the SP's.  But a lot of companies don't employ experienced SQL
Server people, so your encrypted SP's may be safe from prying eyes for the
time being.

Alternatives are extended stored procedures and, if you have SQL Server 2005,
writing procedures with a CLR language.  These require skills beyond T-SQL,
but the code is separate from SQL Server and requires other, more
sophisticated hacker tools to read the source code.